Hi, folks!

So, during the blocker review process in the last few cycles, we have
several times come up against the unfortunate situation that a bug that
in the usual course of events would block a release is discovered
extremely late - say the day before the go/no-go meeting - and at least
some folks have argued that it's sometimes appropriate to not block the
release in this case.

This position has gained quite a bit of acceptance, and we agreed at
the F26 Final go/no-go meeting to draft up some formal policy for this
so we can make such decisions consistently and not in an ad hoc way
that might lead to it becoming a loophole that gets abused.

So, here's my proposal for that. The actual guts of the 'review
blockers' process are kind of split between
https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and 
https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting , so we could
kinda document this in either, but my preference is for the former. I
propose we add a new section to
https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process , called
'Exceptional cases' or similar, as a sub-section of the 'Reviewing
blocker bugs' section. This is my proposed text. Note that it also
covers another type of case we have occasionally come across in the
past, but similarly never specifically formulated.

##################

=== Exceptional cases ===

Generally speaking, any bug that is agreed to be a violation of the
[[Fedora Release Criteria|release criteria]] should be accepted as a
blocker bug for the next relevant milestone release.

However, as explained in the [[Fedora_Release_Life_Cycle|Fedora life
cycle page]] and the
[[Fedora_Release_Criteria#Release_Constraints|release criteria]], we
consider Fedora's release process not to be strictly based on time
''or'' strictly based on quality, but to take both into consideration.
This can mean that, in some exceptional circumstances, we may agree
that a bug constitutes a sufficient violation of the release criteria
that it would ordinarily be accepted as a blocker bug for the next
milestone release, but in fact accept it as a blocker bug for a later
milestone release.

There are currently two established circumstances in which this may
occur.

Firstly, it may occur if it is agreed to be very unlikely that the bug
can possibly be fixed within a reasonable time frame for the release to
be made. For instance, fixing the bug may be a task of such technical
complexity that it cannot possibly be achieved for several weeks or
months, and it may be held that such a delay would be too disruptive to
Fedora's development to be justified.

Secondly, it may occur if the bug is discovered very late in the
release validation process. Sometimes, a relatively less important
blocker bug (such as a non-vital default installed application on a
release-blocking medium failing to run, for instance) may only be found
very near the end of the release validation process, too late for it to
be reasonably possible to fix it without delaying the release. Again,
we may make the determination that in such a case it is preferable to
go ahead with the release rather than delay it to fix such a late-
discovered bug.

All such cases must be evaluated and discussed by the usual parties
(usually at a blocker bug review meeting) and all relevant factors must
be taken into account, much like the discussion of a bug that is a
'conditional' violation of the release criteria. At least the following
will almost always be relevant:

* The severity and likely prevalence of the bug
* Whether the bug could, or should, have been discovered earlier
* How long the release in question has already been delayed
* Whether delaying the release may give us an opportunity to carry out
other desirable work
* The possible effects of the expected delay (to Fedora itself, and
also to other things influenced by Fedora's schedules, including
downstream projects)

It is expected that in almost 'exceptional' cases, the bug will be
accepted as a blocker either for the very next milestone release, or
for the equivalent milestone for the next release (e.g. if this
'exceptional' provision is agreed to apply to a bug that otherwise
would have blocked {{FedoraVersion|long|next}} Final, it should be
accepted as a blocker either for {{FedoraVersion|long|next2}} Alpha or
{{FedoraVersion|long|next2}} Final).

#################

That's a bit wordy (suggestions for cutting it down are appreciated!),
but I think it covers all the salient points. Thoughts? Concerns?
Suggestions? Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to