On Wed, Dec 18, 2024 at 02:21:19AM -0700, Neal Gompa wrote: > On Wed, Dec 18, 2024 at 2:04 AM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > > > On Wed, Dec 18, 2024 at 09:53:17AM +0100, Miroslav Suchý wrote: > > > Dne 18. 12. 24 v 1:38 dop. maxwell--- via devel-announce napsal(a): > > > > The following packages are orphaned and will be retired when they > > > > are orphaned for six weeks, unless someone adopts them. If you know for sure > > > > that the package should be retired, please do so now with a proper reason: > > > > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > > > > > I see lots of packages that are orphaned, but have one or more > > > co-maintainer. Sometimes they may quickly take the package, sometimes they > > > may be on holidays. > > > > > > Would you object if promote a co-maintainer to main maintainer for orphaned packages and make it a rule? > > > > Broadly it is a good idea, but with impl questions due to Pagure. > > > > IIUC Pagure only allows for 1 "main admin" (owner). What would you suggest > > if there are currently 2 (or more) "admin"s (co-maintainers). Arbitrarily > > pick 1 of the many to promote? Or do nothing and let them choose ? > > > > This is a problem I would hope our Pagure replacement will trivially fix > > for us, on the dist-git side at least. Other forges don't typically have > > a distinction between a single "main admin" and other "admins". Repos are > > "owned" by the collective of all admins who are equal peers. So there's > > no problem until the very last admin wants to leave. > > > > One thing I hope we never do is allow something to be principally > owned by groups as a rule. As a general practice, "groups" are bad at > being responsible for packages when the chips are down. It is > difficult to figure out if a package is being administered. Having a > singular point of contact in that scenario is beneficial, and I would > prefer we maintain that going forward in any new system. > > Will we? I don't know. People have been trying to make loopholes for > this for years anyway, and every loophole implementation sucks in > their own way. Just look at all the "foo-maint" accounts that > represent some team for a package. Ultimately those accounts are > useless for being responsible for the package and creates issues for > us over the long-term as we cannot figure out if there's anyone behind > a package in the first place. I can understand your complaint about non-responsive groups, but there are equally plenty of non-responsive individuals too. It all boils down to social expectations for maintainers. If either an individual, or a group, is not sufficiently responsive, technical solutions are not going to solve that for us. > Pagure had the distinction because our policy needed it, and I don't > particularly disagree with that need. Our policy here is ineffective & unenforced, given we have many packages with group ownership via the "foo-maint" alias workaround for Pagure's limitations. Trying to fix social problems with technical solutions often ends up this way, with people forced into sub-optimal workarounds. I don't like the "foo-maint" aliases, because we have no visibility into who is behind the alias, but this is problem of our own making. If Pagure had allowed all admins as peers it would have reduced the incentive to workaround it with "foo-maint" aliases. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
