I think those package should follow the rule, personally, so I agree that we should work to identify one person that becomes the main point of contact for them.

I agree. Having non-user users like this is just creating problems with a lot of our processes, and it would be better to drop them completely. (Note that there's also an obsolete java-sig user, but it looks like it wasn't caught by your queries because it's not main admin for any package.)

All these predate 'pkgdb' groups. amusingly, some ( like gecko-maint, deliberately go to /dev/null)

I agree it would be nice to clean these up, but perhaps it could be done as part of the forgejo move? (since other things around this might change too)

We should cull all of these. I would rather not wait on the Forgejo move since this is a persistent pain right now.

php-zipstream bogomil

This is not a core package owned by fake group user, but a leaf owned by a real user who is not a packager. I filed https://pagure.io/releng/issue/12982 to orphan the package.

As for the other ones, I agree with ngompa that we should try to hand these over to real users sooner rather than later. It'd be good to get this done well in advance of the Forgejo migration so these users don't also get migrated over.

With that in mind, here is a concrete proposal:

1. Bot accounts or any group or other account that is not registered to an individual person — including legacy user accounts that end in -team or -maint and/or have a mailing list set as the user's email in the account system ("legacy group user") — MUST NOT be listed as a package's main admin.

2. Default bug assignees MAY be set to a group or a "legacy group user" using the assignee override feature in dist-git provided that the group has processes in place to triage bugs.

3. For each existing package owned by a "legacy group user", an email will be sent to the maintainers asking them to identify an existing maintainer to be promoted to main admin and file a https://pagure.io/fesco ticket to request the change.

I guess points 1 and 2 can be added as separate subheadings to https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities — or should they be separate policies?

For point 3, I guess I can send the emails. Open question — should maintainers file releng or FESCo tickets? I thought it'd be good to have FESCo double check each change to make sure these very important packages are handed over to trusted maintainers.

(Assisted-by: Nobody. I just like em dashes.)

I guess points 1 and 2 can be added as separate subheadings to https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities

I opened https://pagure.io/fesco/fesco-docs/pull-request/111.

Thank you for working on this, the proposal looks good to me - +1'd the fesco-docs PR.

How would we enforce 'provided that the group has processes in place to triage bugs' ?
Perhaps we should encourage it, or ask groups to document something, but I'm sure some groups are less structured about things than others...

I think it's easier to just say no entirely. If they want group subscriptions to bugs, the lists need to be on the fedora lists server, nowhere else.

For the record, "Default bug assignees MAY be set to a group [...] provided that the group has processes in place to triage bugs" was meant to refer to FAS groups also. There have been cases were people import packages (or branch them for EPEL) and assign them to a SIG group that does not regularly triage bugs and then don't respond to bugs themselves either. On the other hand, the Python interpreters all have a real user as a main admin but the Bugzilla assignee is the python-maint psuedo-user. I think this is fine. The maintainers regularly triage bugs, the python-maint user doesn't have any access to the package, and there is a User:python-maint wiki page that explicitly explains that the user is owned by the Python Maintenance team at Red Hat, who is on that team, how to reach them, and how the user is only used for Bugzilla purposes.

If "the group has processes in place to triage bugs" seems too formal for a project like Fedora, how about changing this to "the group has active members who respond to bug reports assigned to it"?

It's not that it's too formal IMHO, it's that it's too generic and also we have no way to enforce it because of that.

ie, someone can say "our bug triage is ignoring all of them until someone nags us about one' is a process. Not a good process I agree, but a process.

I think we should just say "Default bug assignees MAY be set to a group [...] which makes that group responsible for fulfiling the responsibilities listed in this document."

What about this? The bug assignee is only responsible for triaging and responding to bugs while the main admin and other maintainers/committers are still overall responsible for the package.

diff --git a/fesco/modules/ROOT/pages/Package_maintainer_responsibilities.adoc b/fesco/modules/ROOT/pages/Package_maintainer_responsibilities.adoc
index ed3cca3..ee2806d 100644
--- a/fesco/modules/ROOT/pages/Package_maintainer_responsibilities.adoc
+++ b/fesco/modules/ROOT/pages/Package_maintainer_responsibilities.adoc
@@ -45,6 +45,7 @@ It is recommended that maintainers:
 * Provide test cases of general functionality, for use when testing for regressions
 * On update submission, provide test cases for things fixed in the update, for testers to use

+[#_deal_with_bugs]
 == Deal with reported bugs in a timely manner

 * If you find yourself unable to handle the load of bugs from your package(s), please ask for assistance on the link:https://admin.fedoraproject.org/mailman/listinfo/devel[devel] and/or link:https://admin.fedoraproject.org/mailman/listinfo/test[test] lists.
@@ -103,7 +104,7 @@ registered to an individual, accountable person MUST NOT be listed as a
 package's main admin.

 Default bug assignees MAY be set to a group using the assignee override feature
-in dist-git *provided that the group has processes in place to triage bugs*.
+in dist-git *which makes the group responsible for the requirements in <<_deal_with_bugs>>*.

 == Track dependency issues in a timely manner

That looks good to me! Thank you.

That looks good to me! Thank you.

Thanks. I updated the fesco-docs MR.

fesco-docs MR was merged. Let's keep this open so we can track fixing (by assigning a real main admin) the 18 packages that don't follow this policy currently.

I'm the effective admin of one of the affected packages (systemd), and AFAICT, I cannot change the role systemd-maint which is currently "main admin". So I think this needs releng help.

Proposal to discuss in the meeting today:
We'll send a mail to the list in the initial post, asking who should be the maintainer, and after a week, we'll collect the replies and releng will assign 'main admin' role to the specified people. For packages where no reply was received, the package will be orphaned and another mail will be sent to the current maintainers to remind them to grab the package.

We'll send a mail to the list in the initial post, asking who should be the maintainer, and after a week, we'll collect the replies and releng will assign 'main admin' role to the specified people. For packages where no reply was received, the package will be orphaned and another mail will be sent to the current maintainers to remind them to grab the package.

I don't think we should orphan any of these packages without first having filed Bugzilla bugs and/or sent direct emails to the current maintainers. Sending a devel list post that is not guaranteed to reach the actual maintainers and then waiting only week before allowing core distribution packages to get picked up by any packager does not seem like a good idea.

I'm the effective admin of one of the affected packages (systemd), and AFAICT, I cannot change the role systemd-maint which is currently "main admin". So I think this needs releng help.

Filed https://pagure.io/releng/issue/13011

I sent out messages to the various teams now.

@zbyszek per last week's meeting summary we can review the responses in this week's meeting I guess? So I will keep the meeting tag on.

If we're not ready yet we can just punt to next week.

Just for clarity - was an email sent to the list as well, or just to the specific teams? I could not find the list message.

I send out mails with the fesco list in CC so that we have some record of the conversations.
If I got a reply that the address is not valid, I sent a follow-up to the most active
maintainer.

I got the following replies:
dracut - pvalena
fedora-bookmarks, firefox, mozilla-filesystem - stransky
libvirt - berrange
rpm - pmatilai
seamonkey, thunderbird - xhorak

No reply for those:
anaconda anaconda-maint
device-mapper-multipath lvm-team
device-mapper-persistent-data lvm-team
dmraid lvm-team
isomd5sum anaconda-maint
kernel kernel-maint
lvm2 lvm-team
retrace-server abrt-team

I think that for the cases where there's an obvious person who is active a lot I would just give the package to them. E.g. @jforbes for the kernel.

Might as well just assign kernel to me. For years there was a group and it made sense, but it has been me for a good 5 years now.

This was discussed during today's meeting:

APPROVED Give users / groups one more week (Nov. 4) to
assign a "main admin" and decide upon a default bugzilla contact for
affected packages, and if there are no responses until then, orphan
affected packages. (+6, 0, -0) (@decathorpe:fedora.im, 17:14:29)

The orphaned packages report today again got bounces from packages owned by unreachable users. @zbyszek, have you received a response from the anaconda and other missing maintainers? The installer is a pretty important component, so it's concerning if its maintainers are unreachable.

CC anaconda maintainers: @m4rtink, @toshio, @bookwar, @rvykydal, @kkoukiou

I opened https://pagure.io/releng/issue/13065 based on @zbyszek's list.

The status in my last comment + reply from jforbes is up-to-date. No additional replies.

anaconda folks have been discussing who they want to set, but I don't think they have come to a conclusion yet.

That leaves lvm team and abrt team.

I messaged the person who has been doing lvm2 commits in internal messaging...
not sure who to talk to about abrt. Perhaps @msuchy knows?

abrt stack is @msrb as far as I know, not sure about lvm2

anaconda folks have been discussing who they want to set, but I don't think they have come to a conclusion yet.

We looked into it & I've volunteered to take it. Feel free to set me as the point of contact for Anaconda stuff. :)

libreport and retrace-server can be assigned to me.

I already responded to @zbyszek's email about this on October 21st. stating that I should be the device-mapper-multipath maintainer. Is there anything further I need to do here?

device-mapper-persistent-data - @mcsontos
lvm2 - @mcsontos
dmraid - @mcsontos - but it is removed from newer releases

AGREED: Stephen pings them again and if no reply happens until next meeting, the lvm2 package get assigned to Marian Csontos (+6,0,-0)

It also seems that @mcsontos replied to the ticket in the meantime, so that's going to be even easier for everyone :).
Thanks @mcsontos :)

@bmarzins I created a releng issue on your behalf: https://pagure.io/releng/issue/13080
lvm-team should be now resolved

@mcsontos Thanks.

I updated the releng ticket with the requests for the lvm-team packages. Thank you!

@m4rtink, would you also like to take isomd5sum that's owned by anaconda-maint? That's the only package from my original list that hasn't been accounted for.

Main admins are not allowed to be set to a group, so it goes to reason that a "fake group user" shouldn't be one either. The correct solution for groups (whether RH teams or Fedora SIGs) that want to have Bugzillas assigned to a mailing list is to have an actual person be the main admin and use the Bugzilla assignee override feature in distgit.

I set up lvm-team. You can look on these accounts now as an anachronism which it is good finally to be able to eliminate. Way back when these systems were new, this was the only reasonable way to share control and triage. These special accounts weren't allowed to be packagers (as they were not an entity permitted to sign the agreement) meaning we had to open tickets to do things that normal accounts could do directly so it wasn't a very convenient solution.

All the packages are reassigned now.

If someone could confirm and close this I think we are done.

If someone could confirm

There's still isomd5sum maintained by anaconda-maint that I don't think has been accounted for.

$ goorphans dg rogue-maints
isomd5sum anaconda-maint

Other than that, yes, everything has been assigned.

ok, so we are waiting to hear back from @m4rtink on that one?

I don't think there's anything to discuss here. We're still waiting for a reply from @m4rtink about isomd5sum.

The recent commits to isomd5sum are from @bcl so maybe they want to take over as the main admin instead?

I sent a mail to @bcl.

I talked to the Anaconda Folks and Paweł Poławski has expressed interested, they're working on getting him setup as a packager.