Blocking bugs - juju/juju GitHub Wiki

Current Blockers

Definition of blocking bugs

Master and all release branches should always be in a releasable state. If a bug must be fixed for the next minor release, it is considered a ‘blocker’ and will prevent all landing on that branch.

We block for two reasons:

To prevent problems from becoming compounded by follow-on changes.
As a stop-the-line, all-hands-on-deck signal to get more eyes on the problem.

A regression is a bug that is present in a version of juju that is not present in older juju versions. We are strict about regressions because our goal is to land these changes into Ubuntu, which is treating them as though they were bugfix-only releases.

Regressions compared to juju versions going back to 1.18 prevent releases. This includes CLI or API incompatibility and other behaviour changes. Consistently failing tests will also prevent releases. Although ideally all regressions would block, regressions with limited impact, such as single test failures, do not initially need to block landings. To prevent branches remaining unreleasable for long periods, these bugs will be updated to block after a week.

Handling blocking bugs and regressions

File a bug
Mark as critical, target against next minor release.
Tag "blocker" unless it is a regression with limited impact.
Tag "ci" if it causes a CI test to fail.
If a particular revision introduced the issue, subscribe the author to the bug.
If trunk is blocked, alert the #juju-dev IRC channel or mailing juju-dev list.
If the bug was not tagged "blocker" but is not fixed within a week, tag it "blocker".

Unblocking

All bugs tagged "ci blocker" will be marked fix-released when the branch has a blessed tip.
QA will mark all other blockers fix-released when they determine them to be fixed.
Exceptions are raised to the release team.
The blocker tag should not be removed except by the person who added it or through raising an exception to the release team.