On Fri, 2019-08-09 at 18:26 -0700, Adam Williamson wrote: > On Wed, 2019-07-24 at 10:04 -0400, pmkellly@xxxxxxxxxxxx wrote: > > I got feedback from Adam and Ben today; so the following changes have > > been made: > > > > I have added a little paragraph at the beginning to say what a last > > minute blocker bug is. I used freeze as the time anchor rather than a > > meeting since that seems to be the most firm time constraint we work to. > > Perhaps the review meetings could be anchored to the freeze as well. > > There might be some merit to showing the critical meetings in the > > schedule list that gets published. > > > > I changed "team" to "stakeholder groups" > > > > I removed "proposed" from places where it really didn't add anything. > > > > > > Have a Great Day! > > > > Pat (tablepc) > > Thanks Pat! For future drafts, can you please just send them as plain > text in line? It makes it more convenient to read them quickly. For the > record, here is Pat's proposal: *snip* OK, so here is a new draft based on a kind of merge of Pat's recent drafts and my earlier drafts. For the record, my previous draft was 555 words, Pat's last draft is 258 words (without counting the paragraph numbers and without any wikitext like mine has), and this is 445 words. I think Pat's draft left out some necessary connective tissue, though (like what exactly this concept is *for*, and details on how exactly the review should be handled, and it kinda smooshed together the 'last minute' and 'difficult to fix' concepts), so I don't think I can cut much more. +++++++++++ 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 +++++++++++ -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ 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
