On 11/19/2015 11:40 PM, Adam Williamson wrote:
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?
If a blocker bug breaks phase criteria, then there is no phase exit
unless the bug is fixed. Unless we are ready to risk as it might happen
in certain cases earlier in cycle but such instances should be zero once
we are in Beta. That way, we would still be honoring the phase exit
criteria. As a definition, BlockerExceptions should not contain any
phase exit criteria bugs; these can be related to an important feature
which is partially broken. For the Final phase though, all identified
blockers and blockerExceptions that were carried from earlier phase are
fixed before GA and if there is any exception in this phase out of that
list (after risk assessment), we can consider them for 0day.
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.
Ok. We should probably stop calling them as FEs in that case :) and have
a mechanism to track them on basis of priority and have them fixed
before RC.
Regards,
Sudhir
Regards,
Sudhir
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
