Non-image blocker process change proposal

[Petr Schindler]

Stephen Gallagher píše v Čt 19. 11. 2015 v 15:50 -0500:
> 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.)

+1. I think that even 0day bugs should block the release. When the
update for 0day bug would be available after Go/No-Go and we would
found that it is buggy (doesn't fix bug properly or it creates another
problems) then we would end up with unresolved blocker in release time.
Maybe we could add some rule for delaying release in such cases
(something like big red button - stop release now!).

>From those two proposed solutions I like the second more. To have
another magic words for White board. As I said I think that 0day
blockers should still block the release. But I agree that we should
treat them differently so we should track them somehow.

> -- 
> test mailing list
> test at lists.fedoraproject.org
> To unsubscribe:
> https://admin.fedoraproject.org/mailman/listinfo/test