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