Non-image blocker process change proposal

[Sudhir D]

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