Blocking bugs process

Aaron Bentley aaron.bentley at canonical.com
Tue Jul 14 13:26:01 UTC 2015


-----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-----



More information about the Juju-dev mailing list