On Fri, 2019-08-09 at 19:04 -0700, Adam Williamson wrote: > 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. OK, so based on the follow-ups here, I went ahead and merged this draft, only with '7 days' changed to '5 days': https://fedoraproject.org/w/index.php?title=QA%3ASOP_blocker_bug_process&type=revision&diff=551137&oldid=503308 Thanks folks! > +++++++++++ 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 -- 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
