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 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
