Unblocking master, you can too!
Martin Packman
martin.packman at canonical.com
Fri Aug 28 21:08:46 UTC 2015
CI picked up regression with upgrades today, and Curtis filed the
following blocking bug:
<https://bugs.launchpad.net/juju-core/+bug/1489896>
This was a nice simple case as there was only one change under test,
and the failure also made it clear the changed code was the issue. But
no one jumped on reverting the change when I poked in the channel. So,
here's what I did to unblock master as a reference for future - any
dev can do this.
First, pull master, look at the log, and find the change implicated in the bug:
commit 5656861f7e3f2516aaf1a067d9fee7c876a3de15
Merge: 716cafd d260119
Author: Juju bot <jujubot at users.noreply.github.com>
Date: Fri Aug 28 06:06:51 2015 +0200
Merge pull request #2871 from waigani/last-conn
Make a new branch from master for the revert:
$ git checkout -b revert_pr2871
Switched to a new branch 'revert_pr2871'
Revert that merged revision:
$ git revert -m 1 5656861f7e3f2516aaf1a067d9fee7c876a3de15
This will also commit, and come up with a prefilled message, which I
tend to amend by making the title a bit less verbose and add a mention
of the regression bug being fixed.
In our case with juju, the mainline revision will always be the
left-hand parent, so `-m 1` is what you want. Look down further in the
log to confirm, the left merge sha prefix should be the previous juju
bot commit.
Finally push the branch up and propose it for merging:
$ git push origin revert_pr2871
Afterwards, it's helpful to reopen the bug the original commit was
fixing if one exists, or just mail the list/author otherwise.
The whole process, including eyeballing the diff to confirm the right
stuff was reverted, takes less than ten minutes, so there's no reason
to leave a branch in a broken state.
Martin
More information about the Juju-dev
mailing list