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 :| _______________________________________________ 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
