Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 1556

News	FAQ
Search	Home

Patching the release candidate

Once the release master has been updated, patches for defect resolution and documentation will be sent. These patches are suppose to be sent a binary shar files (shar -B dir/thefile > myfile.shar). In general only defects fixes are allowed for .cc, .h and .g files. Documentation is always welcomed. Steps for patching always done as a user:

• Make a seperate code tree
• Save the shar files into a directory, i.e. /home/tarzan5/wyoung/patches/jun21.
• Edit the files to remove non-shar file text
• Unpack the shar files into a clean code tree,

  cd /home/tarzan5/wyoung/patches
  ./unpack.sh jun21 2&>1 | tee patch.log
  

  Check the log to make sure everything unpacked cleanly. If there are problems notify the sender.
• Patch the release master
  • (adm) Enable checkins in the release master; /export/aips++/scripts/do_enable release
  • (user) Apply the patches

    cd /home/tarzan5/wyoung/aips++
    ../patches/do_patch.sh
    

  • (adm) Disable checkins in the release master; /export/aips++/scripts/do_disable release
  • (adm) Exhale the release
  • (mgr) inhale -R release -c
  • (mgr) check the build log for problems
  • (user) Notify aips2-workers of accepted patches

     cd /home/tarzan5/wyoung/patches
     awk -f okpatch.awk jun21/* > patch.mailing
     mailx -s "Accepted patches for release" aips2-workers@aoc.nrao.edu < patch.mailing
    

    Note: the okpatch.awk script will need to be modified with each new version.