On Mon, 2019-09-16 at 16:11 +0200, Kamil Paral wrote:
On Fri, Sep 13, 2019 at 6:44 PM Adam Williamson
> 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
> > 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
> > marked to have godly powers). If you read the list of automatic blockers
> > , those are broken composes, dead-on-arrival images, incorrect
> > checksums, broken dependencies, and *oversize images*. I don't think
> > but FESCo should be able to say "go" in that case, regardless of when
> > 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
So, it was all about saving time in blocker meetings and being able to
accept obvious blockers quickly.
Here's the full mail:
> 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
> 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.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net