On Fri, Sep 13, 2019 at 10:43 AM 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 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.
While I agree that automatic blockers are more about their unambiguous
nature, it is also unambiguous that image size is presently a beta
requirement. That it can be waived, and also that it was
overwhelmingly waived, very strongly suggests a) it should not be a
beta requirement; b) the present maximum size is incorrect and needs
updating; c) there's some kind of unwritten fudge factor, maybe 5%
oversize for beta is OK but 100% wouldn't be.
Essentially, no one found it intuitively compelling or desirable to
actually block release, even though it's unquestionably a blocker.
Since the bug is not blocking the release tells us it is in fact not a
release blocking bug. It's a blocker in name only, in practice it's
not. It's a contradiction, and thus hilarious.
Anyway, the Workstation working group will revisit the maximum size
issue on Monday, and perhaps there won't be a contradiction on release