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.
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). 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.
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).
_______________________________________________ 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
