Blocking bugs process

[Ian Booth]

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.