Re: Orphaned a lot of (mostly) Go packages owned by @fpokorny
On Thu, Nov 24, 2022 at 12:35:43PM +0100, Miro Hrončok wrote:
On 23. 11. 22 18:44, Daniel P. Berrangé wrote:
> IMHO we would be better off eliminating the notion of 'main admin'
> entirely and have all co-maintainers be at the equal level, so there
> is no need for a dance to give packages to comaintainers. There
> should only be manual action needed if the last comaintainer quits.
The bugzilla default assignee notwithstanding, I am afraid that this would
create 2 more problems:
1) I've seen packages with 15+ nonrepsonsive co-maintainers. Currently I am
glad that I can "just" process 1 non-responsive maintainer thing to get it
orphaned. If a new maintainer takes it, they can clean the ACL cruft. And if
an old maintainer takes it, at lest now they are the ones with
"responsibility". If nobody takes it, it gets retired and the ACLs are moot.
win-win-win. How would this work in this "common ownership" scheme?
The non-responsive maintainer process isn't inherantly tied to
individuals though. The thing is kicked off with filing a bug
against the package asking for a response, and escalates from
there until either there is a response or the package gets
orphaned. Whether 1 maintainer is responsible for ack'ing the
bug, or any of the co-maintainers can ack it feels pretty minor.
2) I've seen packages maintained by groups. If the group does not
regularly
triage their bugzillas or if all of the bugzillas are not miraculously
solved by one "hero", such buzgillas tend to rot. Everybody assumes the
others are responsible. Many group members don't even read bugzilla email
for their group. Often, FAS accounts of long-gone folks are assigned as
admins and the group is set as the main bugzilla contact. This makes
contacting somebody who will care extremely hard for a bug reporter. (I've
also seen groups where this works well, but they are usually either very
well organized or 1-person groups.)
Of course there's never any gaurantee that bugs will get a
response. That's true whether there's a main maintainer with
several co-maintainers, or simply many co-maintainers as peers.
There's nothing special about Fedora packages in this respect,
it is true of all upstream projects too. Bugs are always the
collective responsibility of every maintainer, and unless a
project has a nominated bug triage person, it is not good to
assign all bugs to a specific person. If anything it will make
it less likely to get a response if all bugs get pushed to just
one person, out of many as it isn't scalable.
In terms of FAS accounts who are long gone, that's not an argument
for avoiding a collective maintainer concept. The focus needs to
on identifying accounts who've had no activity in Fedora and
deactivating them and removing them from package maint at some
point, to reduce risk of idle account takeover. This could start
with a reminder alert to the list of maintainers for a package
asking them if idle maintainers still need to retain privileges,
encouraging them to remove dormant accounts. This group self
purging of dormant acocunt would be easier without the 'main admin'
concept that requires the hand over dance
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 :|