> > == 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. >
I don't agree with the above definition. There are always many bugs which must be fixed for the next minor release - these are assigned to the relevant milestones and marked high or critical. We often hold a minor release until all required bugs are fixed; this doesn't make them blockers and should not hold up efforts to land fixes for those and other such bugs. I thought a blocker was defined as a critical tagged ci+blocker. So it's possible to have a critical bug, which would block a release, but not tagged as a blocker. Also, as and stated, even some high bugs are required to be fixed before we release (the current upgrade bug 1468653 a case in point) but by the above definition would be blockers. In the case of bug 1468653, this has been under investigation for 2 weeks and even though we are holding up the 1.24.3 release for it, if it were a blocker the whole production line would have stalled unnecessarily. > 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. > So taking bug 1468653 again (which is not currently a blocker but would be by the above definition), putting more eyes on the problem would not help - the right people are already looking at it. With follow on changes, the problem is quite isolated so landing fixes for other release critical issues should not be prevented. So in summary, I agree with the need to block but not the literal interpretation of the broad scope of the definition used above. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
