On Mon, 2019-09-16 at 16:11 +0200, Kamil Paral wrote: > On Fri, Sep 13, 2019 at 6:44 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> > wrote: > > > 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. > > > > There are two ways how to understand automatic blockers - that they are > based on bug seriousness, or obviousness. I clearly use the former one, and > you the latter one. I guess that's why our views differ. Well, here's what I wrote when I proposed the automatic blocker process in the first place: "There's a few types of blocker bug that are basically no-brainers; it doesn't make a lot of sense to waste time in blocker meetings discussing them, and more importantly, sometimes they show up and we want to quickly accept them as blockers and get the fixes in, but we have to try and track down three people to vote +1 before they can be accepted." So, it was all about saving time in blocker meetings and being able to accept obvious blockers quickly. Here's the full mail: https://lists.fedoraproject.org/pipermail/test/2013-February/113840.html > > > 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. > > > > You've lawyered me here (I should have expected that). You really should ;) > I wanted to argue > that the delaying is supposed to happen before accepting it as a blocker, > but no, you're correct. > > What I see mildly annoying with this approach is that it bring uncertainty > into the process. Before, an accepted blocker was an accepted blocker, and > you could count on that and adjust your priorities appropriately. That > means working on the fixes as a developer, or debugging it more as a QA. > Now, a blocker can be delayed (postponed to a much later date) and so the > dependability on the "AcceptedBlocker" label is suddenly no longer what it > used to be. That's a fair point, but I would say it's a bit limited, as it only applies to the five days before go/no-go. Still, it's true that the 'automatic blocker' process makes this different. As we wrote/considered the 'last minute blocker' policy, without thinking about 'automatic blockers', you could say that the time frame during which a bug was accepted as a blocker but under consideration for 'last minute' status would be very short - as in, a few minutes - and it would never actually be marked in Bugzilla, as all this would happen during a meeting. But now we know that's not quite true, as this exact scenario can happen - it can be automatically accepted and tagged in Bugzilla, then come up for 'last minute' consideration during the next meeting. So the time frame expands from 'a few minutes' to 'a few days'. > > > 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. > > > > I don't disagree here, but that's why I wanted to discuss the process > separately from this particular issue. For me, automatic blockers were > about bug criticality, and therefore my view was that we are too strict in > this particular requirement for Beta release and should resolve it in a > different way (e.g. by weakening the criterion). I still consider automatic blockers to be about obviousness (not criticality), but I'm open to different resolutions here anyway, if we want to come up with something really clear. -- 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
