Blocking bugs process

[James Tunnicliffe]

On 14 July 2015 at 15:31, Ian Booth <ian.booth at canonical.com> wrote:
>
>
> On 14/07/15 23:26, Aaron Bentley wrote:
>> On 2015-07-13 07:43 PM, Ian Booth wrote:
>>> 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.
>>
>> Here's my rationale:
>> 1. We have held the principle that our trunk and stable branches
>> should always be releaseable.
>> 2. We have said we should stop-the-line when a branch becomes
>> unreleasable.
>> 3. Therefore, I have concluded that we should stop-the-line when a bug
>> is present that makes the branch unreleasable.
>>
>> Do you agree with 1 and 2?  I think 3 simply follows from 1 and 2, but
>> am I wrong?
>>
>
> Agree with 1 and 2 (depending on the definition of unreleasable - one definition
> of releasable is CI passing).
> 3 does not follow from the definition though.
>
> A milestone may have many bugs assigned to it that we agree must be fixed before
> we release that milestone. simply because we think those bugs are of high
> importance and fit our schedule in terms of resources etc. Holding up a 20+
> people development team because we have a bunch of bugs assigned to a milestone
> is not practical nor productive. Software has bugs. Bugs are assigned to
> milestones so we can plan releases. We generally agree that we want all bugs on
> a milestone to be fixed prior to releasing (or else why add them to that
> milestone). This does not (or should not IMO) make them blockers.
>
> I am happy with the process we have now. CI passing means a branch is
> releasable. That's our current definition (we wait for a bless before
> releasing). When CI breaks we stop the line to fix CI (and rollback of the
> revision that just landed to break stuff is a viable option there). Some bugs
> that have been around for a while which finally get assigned to a milestone
> should not block landings. They may be complex and hard to diagnose and a few
> people fixing is enough. It doesn't help anyone to hold up the entire dev team
> over such bugs. Whereas a CI breakage you have clear choices - fix quickly or
> rollback to unblock.
>
>
>>> Depends on the changes. I think we should be pragmatic and make
>>> considered decisions. I guess that's why we have the jfdi flag.
>>
>> It's true that the particulars of the bug may matter in deciding
>> whether it should block, and that's why there's a process for
>> overriding the blocking tag: "Exceptions are raised to the release team."
>>
>> I think JFDI should be considered a nuclear option.  If you need it,
>> it's good that it exists, but you shouldn't ever need it.  If you
>> think you need it, there may be a problem with our process.
>>
>
> There have been many times we have legitimately needed jfdi. Dev teams exist in
> a world where pragmatism is usually the best policy, rather than a strict
> adherence to a policy which has the potential to kill velocity for unequal
> corresponding benefit.

+2

If the only thing that needs to change before a release is for a bug
to be fixed, I am quite happy with that branch blocking. If the
situation is more nuanced than that, our process shouldn't hinder us.
As soon as we encode absolutes into an automated process we hinder or
remove our ability to be pragmatic and actually do the right thing.
This is why it is irritating when trunk blocks when we know someone is
working on a fix: we know we are doing valuable work and the issue is
being worked on. We don't need to be hit with the bug fixing stick and
should be able to work as a team on more than one thing. If our
team(s) are working well then if someone needs assistance they should
be getting it no matter if they are working on, not just bugs.

James