Blocking bugs process
John Meinel
john at arbash-meinel.com
Tue Jul 14 09:21:08 UTC 2015
So an interesting thought experiment. What if we made all changes on a
stable series require an associated bug to be able to land the code there.
At least as I understand "blocker" bugs on a given series, it just requires
that the code proposed for landing be associated with one of the current
list of blocking bugs. I'm not talking about 'master', but if you think
about it, if we are backporting/changing/updating a "stable" series, it
seems perfectly appropriate to require an associated bug.
Now, is there a case that certain bugs should actually block fixing other
bugs. I certainly agree that bugs that don't allow us to observe the system
can certainly take priority because otherwise we don't actually know
whether your bug fix fixed anything.
Aside from that I feel like it would only be regressions. Sure there is a
serious problem with 1.2x.y but if we released a 1.2x.y+1 with that same
serious problem, nobody is going to be worse off.
I do like a plan that at any point we can cut a minor release to address
something important.
John
=:->
On Tue, Jul 14, 2015 at 3:43 AM, Ian Booth <ian.booth at canonical.com> wrote:
>
>
> On 14/07/15 09:30, Martin Packman wrote:
> > Thank you for responding Ian.
> >
> > On 13/07/2015, Ian Booth <ian.booth at 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.
>
> 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
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20150714/5cd935d6/attachment-0001.html>
More information about the Juju-dev
mailing list