On Tue, Sep 5, 2023 at 2:05 PM Frantisek Zatloukal <fzatlouk(a)redhat.com&gt; wrote: I see it a bit differently. Even when just considering myself, it amounts to frequent email distractions and non-trivial time spent on it (when summed up). I usually don't just blindly type "BetaFE +1", but try to open the Bugzilla ticket (that's slow) and at least skim through it, whether it is really what it claims to be, whether it is FTBFS or also FTI (sometimes I check myself in a VM or in a container), whether it is a non-important package or could possibly impact the release somehow. This total time is multiplied by people involved in the FE process (not just three), although I understand not everyone spends that much time with it. Then there's someone managing the agreement, it can be included in the blocker meeting (if we don't do it async in time), it lowers the readability of the blockerbugs app page because FTI bugs are high in their number, and of course somebody needs to double-check everything when creating a releng request. It's not terrible, not at all, but especially this cycle I'm starting to think that we need some adjustments (thus this email). Well the process is not presently super simple either. FE SOP [1] says: "FTI bugs may still be rejected in complex cases - e.g. if only one subpackage of an important package fails to install, and the fix might potentially cause problems for more important workflows using other subpackages" This requires at least opening that Bugzilla ticket and reading through it, to figure out whether this is the case or not. If we swapped the approach - reject FTI FEs at Beta, unless they provide a direct justification during proposal - it might actually simplify things - for our team, at least. And the volume of proposed FTIs would go down. Not sure whether it's an improvement for Fedora in general, though. I'm not looking at simplifying my work at the expense of others, I'm looking for ways to optimize the process. [1] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process Yeah, Instead of starting to reject the Beta FTI FEs, I'd say we probably I wouldn't need automation, at least in the first iteration. "Image oversized" is not automated either, but we know we can just tag it "accepted" and go on. A similar approach would be fine. But, as cited above from the FE SOP, this might actually bring us some troubles. So I'm not sure whether we can do this generally, without manual inspection.

On Tue, Sep 5, 2023 at 5:22 PM Adam Williamson <adamwill(a)fedoraproject.org&gt; wrote: This didn't occur to me, you're right. We could update our instructions to tell people to use "--enablerepo=updates-testing" when upgrading to a development release, or at least add it if they see broken dependencies and the upgrade fails to start, but only limited people would find those instructions. It's definitely better in general to fix those packages in the main repo. That sounds reasonable. But would we trust packagers to include this important information ("this is not a simple case...") in their FE proposal, or would we still manually check case-by-case?

On Tue, Sep 05, 2023 at 08:21:18AM -0700, Adam Williamson wrote: Yeah, but... when we are 'go' for Beta, we unlock the stable pushes again, so by the time Beta is actually released, most of those packages are already stable and in the base repo, no? Of course that doesn't help testers, but they likely know how to enable updates-testing? It seems like to me easier to just tell them 'make sure your update is stable before beta release day'. kevin