On Fri, Aug 30, 2019 at 3:11 AM Adam Williamson <adamw...@fedoraproject.org> wrote:
> 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, pmkel...@frontier.com 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! > I'd like to revive this topic. Yesterday [1], the last minute blocker policy was misused (at least in my eyes) to ignore the workstation oversize bug [2], which was already accepted as an automatic blocker. I believe it was an inappropriate solution to the situation, and last minute blocker policy directly contradicts automatic blocker policy, i.e. they can't be used together, and the latter automatically beats the former. As I feel it (and would like to have it), "automatic blockers" imply they are such core and basic issues that they are non-questionable and non-waivable (except by FESCo, which is itself part of the same policy and marked to have godly powers). If you read the list of automatic blockers [3], those are broken composes, dead-on-arrival images, incorrect checksums, broken dependencies, and *oversize images*. I don't think anyone but FESCo should be able to say "go" in that case, regardless of when the problem was reported (even minutes before the final meeting). I'd really like automatic to mean automatic, without any consideration. As a result, I propose that we add a note to the automatic blockers policy description that sounds something like this: "Automatic blockers can't un-accepted (waived), with the exception of FESCo." An alternative option would be to exclude just "last minute blocker bugs" exception, but keep "difficult to fix" exception: "Automatic blockers can't be subject to last minute blocker bugs exception policy." This would allow people in blocker review/Go-NoGo meeting to delay an automatic blocker because it was difficult to fix, but would not allow them to delay it because it was reported too late ("delay" here can mean from F31 to F32, not just Beta to Final). For any other reason, the issue would have to be raised to FESCo. I think the first proposal is better, but the second version works for me as well. Anything that we don't deem "absolutely essential" should not be part of the automatic blocker list. If we're OK with not keeping the maximum image size during Beta, we should not have it there. The same applies to anything else in the list. Don't misunderstand my email. I'm glad that F31 Beta is go. And I'm also not sold on the idea of delaying Beta release because Workstation image is 50 MB over size. But I believe we shouldn't sacrifice our policies consistency to achieve that goal. That's why I want to clarify our policies. And then we can talk about dealing with this particular situation in a better way (by excluding Beta image sizes from automatic blockers, or perhaps keeping them just for release-blocking optical images, or bumping the Workstation maximum size, improving our QA processes, etc). Thanks, Kamil [1] https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-12/f31-beta-go_no_go-meeting.2019-09-12-17.00.log.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=1751438 [3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Automatic_blockers
_______________________________________________ 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
