On Thu, 2020-04-16 at 17:06 -0400, Ben Cotton wrote: > We learned in today's Go/No-Go meeting that the late blocker > exception[1] has an edge case when the release slips. Currently, it > suggests[2] that the bug becomes a blocker for the next milestone. In > the case of a Final wallpaper bug, that doesn't make sense. > > I propose the exception be changed FROM: > > > Last minute blocker bugs - bugs proposed as blockers 5 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. > > TO: > > > Last minute blocker bugs - bugs proposed as blockers 5 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. If the release is declared go, the bug can instead be accepted as a blocker for the next milestone release. If the release is declared no-go, the bug loses last minute status. > > In other words, we can choose to waive a bug, but if it turns out we > have another week, then the bug is no longer waived. We could, of > course, later choose to waive it under the "difficult to fix" > exception when appropriate. This would allow us to just make a > decision independent of other bugs, but still allow the bug to be > fixed when the release date slips. > > [1] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases > [2] I say "suggests" because the word is "can", not "must" or similar. > It's word lawyering, yes, but that's what I enjoy. :-) I think I'd prefer to just revise the process to how we did it today: first review all proposed blockers and just decide on whether they're accepted blockers, *then* decide if want to discuss waiving any. And we either have to waive all outstanding accepted blockers or not waive any of them. Still, I can see some awkward cases possible here. We might hit something very awkward that would require months of upstream work and want to waive it even though the release is slipping a week, for instance. That seems to be a problem for either approach... -- 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
