On 14/07/15 09:30, Martin Packman wrote: > Thank you for responding Ian. > > On 13/07/2015, Ian Booth <[email protected]> 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.
By the definition given "If a bug must be fixed for the next minor release, it is considered a ‘blocker’ and will prevent all landing on that branch." that bug and any other that we say we must include in a release would block landings. That's the bit I'm having an issue with. I think landings need to be blocked when appropriate, but not by that definition. > >> 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. > Depends on the changes. I think we should be pragmatic and make considered decisions. I guess that's why we have the jfdi flag. -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
