Bug fixes and patching - juju/juju GitHub Wiki

Migrated to discourse


juju and Bug Fixes

When fixing a bug that affects more than a single branch the prefered process for fixing the bug is to perform the work against the oldest branch (back porting) and then apply that patch up to each release branch and finally in to master.

For example, if a bug is reported to impact R1, R2, and master. You would perform the work against a branch of R1. When your fix is ready you would use the pull request and review process. See: [reviewboard] Then you would apply your fix to R2, and finally once your fix was merged in to R2, you would apply the fix to current master.

How To Backport

Once your inital fix has been merged by the bot (the back port) the process of applying your patch can be done with a few git commands. In this example I will show you applying the fix in to master.

You will want to locate the SHA for the merge commit that was generated by jujubot. This will be viewable on github or in your git log output. Copy the SHA since we will use it to cherry-pick the fix in to master.

git checkout master
git checkout -b <fixed-branch-name>
git cherry-pick -m 1 <merge-commit-sha>

You may have some minor merge conflicts with the cherry-pick that need to be fixed, this is rare when back porting the change first, but occasionally it does happen.

git push your-remote <fixed-branch-name>

Now your new branch is ready to follow the same pull request and review process as the original fix. Be sure to note that this is a patch from a backport and link to the previous review.

Patching 3rd Party Libraries

Sometimes upstream can take months or longer to accept a patch, or even acknowledge it. In order to apply said fixes in releases/tests you can add a patch to the juju patches directory.

It then applies those patches during CI runs from the $GOPATH/src directory with the first path element removed. SO like the following from $GOPATH/src.

patch -p1 < $GOPATH/src/github.com/juju/juju/patches/your-patch.diff

Patch files should have the extension .diff or .patch.

So if you were patching something in mgo v2 the start of the patch would look something like:

diff --git a/afile.go b/afile.go
index 59723e6..1c72091 100644
--- a/gopkg.in/mgo.v2/afile.go
+++ b/gopkg.in/mgo.v2/afile.go
@@ -30,43 +30,29 @@ import (
 	"sync"
 )

There is a README in the patchces directory with some additional information.

Credit goes to babbageclunk (Christian Muirhead) and mgz (Martin Packman).