Do not land code on blocked branches
Martin Packman
martin.packman at canonical.com
Sat May 2 22:13:49 UTC 2015
It has been great that everyone has been diving in and tackling the
backlog of bugs over the last week. However, please only merge pull
requests that are actually fixing bugs blocking that branch.
In particular, the JFDI instruction to the lander is an escape hatch
to allow for merging in extraordinary circumstances, and is not for
landing non-blocking bug fixes.
If you think the bug your pr is fixing is actually a critical blocker,
but CI is preventing it landing you should first:
* Check if the launchpad bug is correctly targeted to the series you
are landing on.
* Ask Alexis, Wes, or your team lead to escalate the bug if it's not
marked as blocking.
In the last three days, master has gone from just two failing test
cases, up to ten:
<http://reports.vapour.ws/releases/2577>
<http://reports.vapour.ws/releases/2593>
CI and the QA team has been busy with releases for the 1.22 and 1.23
branches, adding a large number of regressions to master over this
time period is unhelpful.
Curtis has filed three new bugs for these so far, and there appears to
be one or two more to come:
<https://bugs.launchpad.net/juju-core/+bug/1450912>
<https://bugs.launchpad.net/juju-core/+bug/1450917>
<https://bugs.launchpad.net/juju-core/+bug/1450919>
What I wanted to do was back out Nate's branch as the likely culprit
for the windows test suite regression, but with 13 other branches
landed since then that's no longer a straightforward inference.
Martin
More information about the Juju-dev
mailing list