On Sat, Aug 10, 2019 at 4:04 AM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
+++++++++++ DRAFT START +++++++++++
=== 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, bearing
in mind the [[Fedora_Release_Life_Cycle|Fedora life cycle's]] emphasis
on '''both''' time '''and''' quality, in some cases we may make an
exception. There are two main categories of bug that may be
'exceptional':
# '''Last minute blocker bugs''' - bugs proposed as blockers 7 days or
fewer before the scheduled [[Go_No_Go_Meeting]] for a milestone release
(Beta or Final) can be considered under this policy, as there are some
circumstances in which we believe it is not sensible to delay an
otherwise-impending release to fix a bug which would usually be
accepted as a blocker if discovered earlier. In these circumstances,
the bug can instead be accepted as a blocker for the ''next'' milestone
release.
# '''Difficult to fix blocker bugs''' - bugs which it may not be
practical to fix within a reasonable time frame for the release to be
made (due to e.g. complexity or resource constraints)
The stakeholder groups must first agree, following the procedures
described above, that the bug violates the release criteria and so
would otherwise be accepted as a blocker bug for the imminent release.
After that, the stakeholder groups may separately make a decision as to
whether to invoke this policy and consider delaying the blocker status
to a future milestone release. Anyone attending the meeting (or
otherwise taking part in the discussion, if it is being done outside of
a meeting) can suggest that this evaluation be done. In making the
decision, the following factors can be considered:
* How prominently visible the bug will be
* How severe the consequences of the bug are
* How many users are likely to encounter the bug
* Whether the bug could or should have been proposed earlier in the
cycle
* Whether the current stable release is affected by the bug
* Whether delaying the release may give us an opportunity to carry out
other desirable work
* Possible effects of the expected delay on Fedora itself and also to
downstream projects
* Whether an additional delay to fix the bug, combined with any prior
delays in the cycle, results in the total delay becoming unacceptable
in regard to the [[Fedora_Release_Life_Cycle]]
In almost all 'exceptional' cases, the bug should be accepted as a
blocker either for the very next milestone release, or for the
equivalent milestone for the next release (if it would not violate the
criteria for the very next milestone). For very complex '''difficult to
fix''' cases, a longer extension may be needed.
+++++++++++ DRAFT END +++++++++++
Whether this new policy is a good idea, that's a separate question. The idealist in me cries every time we sacrifice quality. And this policy will probably result in more bugs being waved compared to the past. However, I feel it's better to have the rules formalized than to wave such bugs without any real grounds and feel like cheating on our policies every time we actually need waive something. So yeah, I guess I have no objections to this being a part of our release criteria.
_______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
