Patching a Branch

Edited to use Git and cherry-picking.

How? ("Who" in parenthesis)

• (QA): Find an error in the binaries, determine if it needs to be patched, and alert the Developer.
• (Developer): Create a Build Patch issue in redmine. Fix the error (and get a second opinion on your fix from another developer). Let the QA person know that it is fixed.
• (QA): Verify the developer's fix on hgwdev. Send email to Build-meister (cc'ing browser-qa and developer) with revision number of the fix and patch request (including an explanation of the problem and the fix and the CGIs that will be affected).
• (Build-Meister): You should try to review the commit id to be cherry-picked.

  git show <commitid>
or
  git show --stat <commitid>
 The cherry-pick script will show you a summary anyways.
NOTE FROM GALT: this paragraph seems confused:
Check the Git log to make sure that you are making the correct change.
hgwdev> cd $BUILDDIR/v${BRANCHNN}_branch/kent/src
hgwdev> git log hg/someCgi/someFile.c
hgwdev> ssh -X build@hgwdev          # the optional '-X' allows X-windows support    
<build@hgwdev> cd $BUILDDIR/v${BRANCHNN}_branch/kent/src
<build@hgwdev> git log hg/someCgi/someFile.c

• (Build-Meister): Add the commit(s) to be cherrypicked onto the release branch.

hgwdev> ssh -X build@hgwdev          # the optional '-X' allows X-windows support    
<build@hgwdev> cd $WEEKLYBLD
<build@hgwdev> edit CherryPickCommits.conf

• • Remove all the lines from the last time you edited this. These got logged into a file already.
  • This is a list and you can have more than one line if you need.
  • Each commit to be patched goes no its own line.
  • Edit this file to include the git commit hash id like so:

96b0dc9826d589e09daf2bd1a36ef513c91255b1

• (Build-Meister): Do a test run and verify that everything is set up correctly:

<build@hgwdev> ./cherryPickCommits.csh >& logs/v$BRANCHNN.patch1.log

• (Build-Meister): If it is correct, run it for real:

<build@hgwdev> ./cherryPickCommits.csh real >>& logs/v$BRANCHNN.patch1.log

• (Build-Meister): Determine which CGIs are affected by this file change:
• (Build-Meister): Go to the current build:

<build@hgwdev> cd ${BUILDDIR}/v${BRANCHNN}_branch

• (Build-Meister): Do a 'make' in the library directory, if necessary. If .h files were changed use make clean, either at CGI, or lib level. If the file change was a lib file, then do a make in the corresponding lib directory:

<build@hgwdev> cd ${BUILDDIR}/v${BRANCHNN}_branch/kent/src/lib>
<build@hgwdev> make

• • -or-

<build@hgwdev> cd ${BUILDDIR}/v${BRANCHNN}_branch/kent/src/hg/lib>
<build@hgwdev> make

• (Build-Meister): If only one or two programs are impacted by the change, do a 'make beta' in their CGI directories:

<build@hgwdev> cd ${BUILDDIR}/v${BRANCHNN}_branch/kent/src/hg
<build@hgwdev> cd path/to/c/file   # e.g.: cd hgTracks
<build@hgwdev> make beta

• • -or-
• (Build-Meister): If all or many are impacted, do a 'make beta' in hg/:

<build@hgwdev> cd ${BUILDDIR}/v${BRANCHNN}_branch/kent/src/hg
<build@hgwdev> make beta

Rsync binaries to hgwbeta machine. BE CAREFUL not to over-write hg.conf* files on hgwbeta:

<build@hgwdev> rsync -a -P --exclude=hg.conf --exclude=hg.conf.private \
 /usr/local/apache/cgi-bin-beta/ qateam@hgwbeta:/data/apache/cgi-bin/

Note if you did a full make beta in hg, you may need to do these too, which update htdocs, js, and style dirs:

<build@hgwdev> rsync -a -P          /usr/local/apache/htdocs-beta/       qateam@hgwbeta:/data/apache/htdocs/
<build@hgwdev> rsync -a -P --delete /usr/local/apache/htdocs-beta/js/    qateam@hgwbeta:/data/apache/htdocs/js/
<build@hgwdev> rsync -a -P --delete /usr/local/apache/htdocs-beta/style/ qateam@hgwbeta:/data/apache/htdocs/style/

• (Build-Meister): Update the redmine ticket that the build has been patched and binaries made on hgwdev and synced to hgwbeta.
• (Build-Meister): Update or re-do gbib build steps.
• (Build-Meister): If the final build-wrapup has already been done, you will need to re-do the relevant parts (minimally, the beta branch and release tag (vNNN_branch.1 ->.2) and source.zip would have to be re-done.
• (QA): Test the change on hgwbeta.
• (QA): Reply to the email about the efficacy of the change.

---

Here is an example narrative about the process from a patch in v329: In a typical case, an engineer's fix would be committed and pushed to a shared repo already on the main master branch (the one that most of us use). Hopefully, after that, the developer will also have remembered to recompile the relevant CGI (hgTables or hgTracks here?) on hgwdev, so that you can test it there. This helps you confirm that the fix works. The next step after that is the patching. The buildmeister (Hiram) has already made a special new branch called v329_branch which represents our official version 329 release. We make it so that we can isolate the release from other ongoing development on master. This allows us to test and fix things on the branch without having to merge in other work happening on master. In any case, the buildmeister has a little script that grabs the commitId for the patch from the master branch and applies it to a special sandbox with branch v329_branch so that we can get the correction onto the release. No other changes come with it, just the commit being patched. After buildmeister patches, he will recompile some or all of the CGIs, and then they get rsynced to hgwbeta. At that point we can verify by testing on hgwbeta that the fix works there too, just to double-check the patching worked -- which it nearly always does.