On Thu, 2022-02-10 at 16:57 -0500, Ben Cotton wrote: > On Thu, Feb 10, 2022 at 1:39 PM Zbigniew Jędrzejewski-Szmek > <zbyszek@xxxxxxxxx> wrote: > > > > since you have the script handy, could you check how many (non-pp) > > packagers would be reported as inactive pretty please? Maybe with the > > inactivility threshold raised to 1 year instead of 0.5 y. > > I had to run it a second time with the listing disabled because the > first time the output was too long for my terminal's scrollback. :-) > > But! Of 2453 packagers, 1514 have not submitted a Koji build since at > least 2021-02-11. 1311 of those have not submitted a Koji build since > at least 2020-02-06. An additional 113 do not exist in Koji. > > > I think that if we disabled completely inactive accounts after a year > > or two, this would be reasonable from security perspective. There are > > many many packages which are now maintained by other people so packagers > > can effectively maintain co-ownership without committing to a package > > for years. > > I have concerns with this approach. I would guess there's a long tail > of packagers that maintain relatively few packages. These packages > might not have frequent upstream releases or require new manual > builds. Someone who hasn't needed to build a package in 13 months may > still be active in other ways and it would be hostile to strip them of > packager permission in that case. We'd want to be very careful about > how we define "active" (which is a thorny question project-wide that > we don't have a great answer for). We'd also want to give people the > chance to say "no, I'm still here", which makes this a fairly manual > process. If we were to automate it, we absolutely should have a > trivial way for people to regain packager status (i.e. not have to get > re-sponsored, etc). > > I would support removing the 113 who don't exist in Koji. And maybe > any packagers without a build over an exceedingly long period of time > (say 5 years?) as a starting point. Some may be backups for others, and do not normally create builds but collaborate to the maintenance via patches. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
