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
, 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.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net