On Tue, Sep 5, 2023 at 2:05 PM Frantisek Zatloukal <fzatl...@redhat.com> wrote:
> 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? > 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). > I don't feel like further complicating our processes and guidelines. > 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 > 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.* > 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.
_______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
