On Fri, 2019-09-13 at 13:53 +0200, Kamil Paral wrote: > 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. FWIW, I respectfully disagree with this. The key factor for whether something goes on the 'automatic' blockers list is *whether it could possibly be ambiguous*, not how waivable it is. It happens to be the case that *most* things that are really non- ambiguous are terribly critical things we would never postpone under the last-minute policy - like an image simply failing to boot. That kinda makes sense if you think about it: catastrophic things tend to be very clear. But it's also possible for something to be very clear but not necessarily critical. To me, the size limits - at least, ones which don't match any significant media size - are that. Size limits are on the automatic blocker list because there's really no need for three teams to debate and vote on whether one number is bigger than another, not because exceeding the size limit is a catastrophic bug. Note also that under the last-minute blocker policy as written we're supposed to *first* decide that the issue is a blocker - i.e. accept it in principle - *then* decide to push that status to a later milestone. i.e. the policy effectively applies to bugs that are accepted as blockers. The process isn't that we reject the bug as a blocker under the last-minute blocker policy: the process is that we accept it but agree that moving it to the next milestone is acceptable. So, I don't think the incompatibility between the two policies is that bad at all. I think we could simply clarify that the last-minute blocker policy can also be applied to bugs that have already been accepted under the 'automatic blocker' policy, so long as they were *proposed* within the 5 day time limit. To me this was actually a very appropriate bug for the last-minute policy: it's a not-terribly-critical problem that, through process failure, was only raised at the last minute even though it was known about for ages. I feel bad for not noticing it had been failing for two months, but I don't feel bad about applying the last-minute blocker policy to it. I don't think releasing a Beta with a Workstation live image that's 2.04GB in size instead of 1.99GB in size is going to cause Fedora huge problems. -- 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
