Thank you for responding Ian. On 13/07/2015, Ian Booth <ian.bo...@canonical.com> wrote: >> >> == 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.
So, my argument over this was a pretty strict interpretation of "must". There are lots of bugs with less-than-critical severity that get targeted at the next minor milestone, and I think that's perfect reasonable. However, there are comparatively few bugs that could not be deferred if, for instance, we discovered a security issue and had to rush out a new minor release immediately. From my perspective, blockers are things that break CI enough to hinder our ability to do a release, or issues that if we allow into release code will break users in unrecoverable ways. I know Aaron prefers a much wider interpretation however. > 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. That's an interesting bug. It seems with a lot of pain (manually restarting things) it is actually repairable, and does involve a pretty specific setup. I don't think I'd have added the blocker tag to it, but that may not be the consensus. > With follow on changes, the problem is > quite isolated so landing fixes for other release critical issues should not > be prevented. The fact it's a somewhat isolated problem is important. What I really want to avoid is the case where we leave say, upgrades broken as a whole, and keep landing code. That makes it impossible to tell if following changes also have upgrade problems, or compound the existing issue. Likewise, if we have CI tests failing, subsequent landings make identifying and deal with further regressions vastly more painful, and hose our release process. Martin -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
