Non-image blocker process change proposal

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/18/2015 07:36 PM, Adam Williamson wrote:

> With either approach, the basic goal is to make it more feasible
> to keep an eye on each of the different categories of 'release
> blocker' bugs; right now we have solid processes in place for
> ensuring the 'normal' blockers are all addressed in the release
> media, but we don't have any processes in place for ensuring 0Day
> and Stable bugs actually get updates shipped when we say they
> must.
> 
> My suggestion would be that we make sure 'blockerbugs' includes
> lists of each type of blocker. Ahead of and at Go/No-Go meetings,
> we would want to have a formal assurance from the person
> responsible for fixing the bug that the fix would be provided by a
> certain time - say, one day or two days ahead of the release date -
> and it would be QA's responsibility to ensure the updates are
> tested promptly, and releng's responsibility to ensure they are
> pushed on time after being tested. I would suggest the Program
> Manager ought to have overall responsibility for keeping an eye on
> the 0Day and Stable blocker lists and making sure the maintainer,
> QA, and releng all did their jobs on time.

The biggest issue is this, I think. We probably need to encode
"Special Blockers" into the Go/No-Go process. I don't think that
assurance that it will be fixed on time is necessarily good enough.
Particularly given the time that it takes stable updates to make it to
the mirrors, I'd say that we probably want to say that any such
special blockers have to be queued for stable before the Go/No-Go
decision is made. (This may in some cases mean *during* the Go/No-Go
meeting, of course.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlZONh4ACgkQeiVVYja6o6NJHwCfdWPSKY4S93wc5fUVburm4sk8
CAsAmQGuVqpjixhnitIES0ratHTJg8RJ
=8Jxq
-----END PGP SIGNATURE-----