On Tue, Sep 17, 2019 at 10:35 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote:
On Tue, Sep 17, 2019 at 9:55 AM Kamil Paral <kparal@xxxxxxxxxx> wrote:
>
> Considering this, I believe it makes sense to move the current criterion from Beta to Final.
>
I'd be okay with letting the responsible team specify a buffer they're
willing to accept for Beta (e.g. so Workstation might say "we can
allow 10% over our specified limit" and Server can say "if we go over
the DVD won't burn, so what's the point?") In other words, any overage
would be an automatic blocker, but teams can optionally pre-approve
exceptions. This way, teams can still make determinations that are in
the best interests of the deliverable they're targeting, but we don't
end up in a position we're slipping a week because a deliverable is 5
bytes larger than desired.
While this sounds good in theory, I feel that it's over-engineering. It will be maintenance heavy for automated tests (to ensure the values hardcoded in the script match the wiki page or whatever true source there is) and it will be extremely painful to check manually (counting the numbers). It also makes a rather trivial thing quite complex. Boy, I had no idea this proposal would get so debatable :-) I'd rather keep the current situation (block hard for Beta) than complicate it so much.
I like this approach better than just moving the criterion to Final
because in cases of large overages, the package gymnastics that might
be required to make it work could prove to be pretty impactful. I'd
have a lot more confidence in our ability to deliver a good experience
to our users if we're trying to trim half a gig from an image before
Beta than if we're doing it on the Monday before Go/No-Go.
Yes, but in all those years I don't remember a situation where we needed to shave more than 100MB or so. You don't get 500MB+ growth from some new library dependencies. And in cases where such a growth was at least semi-excepted, the image maximum size limit will probably get updated anyway.
_______________________________________________ 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
