On Tue, 2025-04-15 at 08:08 +0200, Simon de Vlieger wrote: > On Mon, Apr 14, 2025, at 11:56 PM, Michel Lind wrote: > > Dear all, > > > > Over the past months FESCo has been considering my proposal to have > > a > > lighter weight process to get needed changes for Fedora packages > > (whether getting a PR merged and built, or a package branched, > > etc.) - > > since the alternatives up to now is just pinging a PR or bugzilla > > issue, or escalating and getting the maintainer declared non > > responsive. > > > > We think we have a suggested process that would work well - thank > > you > > to everyone in the committee for their inputs - but would like to > > get > > community feedback on this, since we’re only human and there might > > be > > something we miss. > > > > Hopefully this balances out the need to get fixes in, with not > > bypassing maintainers’ concerns (or surprising them with a fait > > accompli if they’re on vacation, busy at a conference, etc.). But > > please chime in and let us know of any improvement we can make to > > this > > before it lands. > > If I read the proposed process right the lightweight part of it is > that this > process can/should be started before the "noticing that the > maintainer is not > answering their bugs, etc". Is that what lightweight refers to here? > There's > also less involvement from FESco so it might also refer to that? :) > The lightweight in this case is also the scope - with this process you end up getting access to one package. With the full non-responsive process all the maintainer's packages get orphaned and people need to scramble to pick them up.
FESCo is still involved both in the old and new process - but the full process has a big impact if executed fully, so we generally abort if the maintainer pops up and say "hey, I'm still here" - in practice this ends up meaning a lot of forward progress can be stalled by a maintainer that is active enough to respond and cancel nonresponsive processes, but otherwise are not sufficiently involved in processing the request (be it reviewing and merging PRs, or branching a package for EPEL, etc.) In some case orphaning all of a maintainer's packages might still be necessary - which is why I am not suggesting dropping the old process entirely. > > My feeling is that if the written up process could do without much of > the > process and instead have a written down process that expedites PR > merges by > provenpackager(s) or FESco directly. Something akin to: > > 1. Day 0: open PR > 2. Day 7: ping maintainer. > 3. Day 14 (or 21): FESco issue to get PR merged. > > Without taking on co-maintainer role. Though maybe that was probably > a conscious choice to have a barrier for using this process? > Yes, this is partly a conscious choice - we don't really want this to be used for drive-by contributions. If you can't convince the maintainer to give you access yourself, and FESCo needs to be involved, then you should own any issue that arises and being a co-maintainer is part of that. Partly it's technical - unless you're a proven packager, if you build a package for which you're not in the ACL you can't submit an update in Bodhi. So in practice you can only build it for Rawhide (where the update is auto-submitted for you). Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README
signature.asc
Description: This is a digitally signed message part
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
