On Tue, Sep 5, 2023 at 12:31 PM Kamil Paral <kparal@xxxxxxxxxx> wrote:
Lately we've seen a surge of FTI (fails to install) bugs being proposed as freeze exceptions [1] [2]. We generally grant them, because we want the base repo to be in a consistent and buildable state. However, I wonder, isn't this approach mostly relevant for the Final release?
Yes, you're right.
Does it make sense to also have this approach for Beta?
Since the freeze lifts after the beta release, it's not technically necessary to address these issues for Beta.
The reason why I'm thinking about this is because of course there's some work connected with granting and processing these freeze exceptions (FEs). But at the same time, updates-testing is enabled by default, so users can get the fixed versions immediately, and the fixes can be pushed stable right after the Beta freeze is over. Is the extra FE-related work justified?
The added work for a FE seems pretty minimal to me (3 people write +1, I push it to the accepted FE in about a minute), not sure if the releng perspective is different here though?
One reason I can think of is when the package A in question needs to be used for rebuilding/installing another package B. In that case, if package A is not pushed stable, you can't prepare an update for package B into updates-testing (or can you? Can you build several inter-connected packages together and make a Bodhi update for them? What if you have access rights to just package B but not A?). I do understand that in this case waiting until the freeze lifts might be inconvenient.What if we granted FEs for Beta just in these justified cases but not in general, in order to decrease the processing-work? Is that a good/bad idea?
I don't feel like further complicating our processes and guidelines. And having another special cases defined somewhere isn't going to work imo.
Or perhaps we can grant FTI FEs automatically? Either always, or in some cases?
Yeah, Instead of starting to reject the Beta FTI FEs, I'd say we probably should just automatically approve all of them? Adding something like this to the blockerbugs sounds very easy and straightforward, and would save us some time in the final cycle:
Does bug depend on the FE tracker? Is the reporter "Fedora Fails To Install"? Does it have an update marked as fixing the bug? Fine, approved, next.
Best regards / S pozdravem,
František Zatloukal
Senior Quality Engineer
Red Hat
_______________________________________________ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue