Blocking bugs process

[Nate Finch]

I think everyone's agreeing here, but maybe the wording just needs to be
clarified somewhere to avoid confusion.

It sounds like "bugs which are assigned to a release do not block commits
unless they are marked blockers".   And blockers are determined by "we
wouldn't want *anyone* to upgrade to a version with this bug in it".

I agree that if a blocker is found in an earlier minor version, that
upgrading to a new minor version with the same blocker doesn't make anyone
any worse off.  However, if we don't make it a stop-the-line, then we need
some other way to ensure that the bug actually gets fixed ASAP....
otherwise it could just tag along minor after minor and not get addressed.
I don't think it's unreasonable to just make such a bug a blocker, just to
get it addressed ASAP, even if it is not strictly making things worse than
an earlier version.

On Tue, Jul 14, 2015 at 9:26 AM Aaron Bentley <aaron.bentley at canonical.com>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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?
>
> > 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.
>
> Aaron
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJVpQ3pAAoJEK84cMOcf+9h4wYIALzMezSmErdb8Gjuq89aRVU/
> CKXZGJ7fWDrsogmsBDOdNhjmtOiIkUIQiZhd3UW5+2WlC+8eix5weJGBWKIo21gx
> 1hLvR6p6SnZ4zlfxV0RV0pbnfq6RqySEV9agnXzM//H/iqDwZp74ELCgR/1mLkXh
> yr19JH1TVx35emqNgO6yFqFVUU6khLPM4JyJ47cjcrDip5f0qLj4gf0nRRE+rasa
> uL1bJc47P0HnLr9xKxBWAioo4OMMb2RAUsgApznXWlqu/P3+TVk1eMQf7Vk1XHV8
> DbqZgMLz5iJHFpI5T6IUPeeo6BOBz+zhfse6MCqOcOavpsJTzrysMLiqrCpUYt0=
> =KeYb
> -----END PGP SIGNATURE-----
>
> --
> 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/940d6f22/attachment.html>