Non-image blocker process change proposal

[Adam Williamson]

On Thu, 2015-11-19 at 19:09 +0530, Sudhir D wrote:
> 
> I suggest we have only one ZeroDay i.e., for Final and do away with 
> intermediate ones.
> As I see it, ZeroDay comes with cost and we also need to have basic 
> sanity testcases automated to ensure ZeroDay fixes won't 
> introduce/regress blocker.
> 
> How about automatically qualifying any freeze exception in current phase 
> as blocker for next phase and keep 0day only for RC?
> AlphaBlocker --> AlphaFreezeException --> BetaBlocker --> 
> BetaFreezeException --> FinalBlocker --> FinalBlockerException --> ZeroDay
> 
> This would mean we will be not so liberal in allowing blockers linger 
> around in a phase for more time, but I think that is okay tradeoff.
> 
>  From tracking perspective, I think we may just want to have trackers 
> for phaseBlocker for each milestone and FinalBlocker and 0Day for Final 
> along with backPortfix tracker one for the pending release, and one for 
> previous stable releases.

Well, the thing is, the criteria are organized by milestone, and we hit
this situation quite often at Beta: the upgrade criteria kick in at
Beta, for instance. So if upgrade from F23 to F24 Beta is completely
broken, but the fix has to go out as an F23 update, we should really be
tracking that to make sure it does. If we only make sure the fix goes
out by Final, are we really honouring the criteria properly?

I don't think it's appropriate to turn FEs into blockers automatically,
in fact there are obvious cases where it certainly wouldn't be
appropriate: bugs in non-blocking desktops are typically taken as FEs,
for instance, as are bugs in secondary arches. Neither of those can
ever be blockers by policy.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net