Re: Promoting co-maintainer to main maintainer for orphaned packages?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Pagure had the distinction because our policy needed it, and I don't
particularly disagree with that need.



-- 
真実はいつも一つ!/ Always, there's only one truth!
-- 
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux