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 02:15:23PM +0100, Pierre-Yves Chibon wrote:
> On Wed, Dec 18, 2024 at 09:03:45AM +0000, Daniel P. Berrangé 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.
> 
> It's not actually a pagure problem, the reason we have a main admin is basically
> bugzilla. You can have as many CC as you want in a bugzilla bug, but there can
> only be 1 account assigned to the ticket.
> This is why in pkgdb we had an "owner" which got changed to "point of contact"
> in pkgdb2 and "main admin" in pagure.

Oh good point. That's actually one of the main reasons many teams create a
'<blah>-maint' email alias, both in Fedora and RHEL world. It gets rid of
the mis-leading impression for new bugs that a specific single person out
of all the co-maintainers is responsible for that bug. A real human does
not get assigned until it is genuinely something they're intending to work
on, so other co-maintainers have a clear view of what's pending or not. I
recall Fedora in the past had unique email address aliases per-package
which would fan out to all maintainers, which could have been used in BZ,
avoiding the need to limit Pagure due to BZ's design.

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




[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