On Sat, Aug 10, 2019 at 4:04 AM Adam Williamson <adamw...@fedoraproject.org> 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 +++++++++++ > That's very well written and I don't have any concerns about its wording. I'm a bit hesitant whether 7 is the right number, but we can try it and see. 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@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
