Watchers can be found at: https://src.fedoraproject.org/api/0/rpms/rubygem-sqlite3-ruby/watchers

Maintainers can remove themselves from packages. Can you share why you would like this to be something infra does rather than the maintainers themselves when they see fit?

Watchers can be found at: https://src.fedoraproject.org/api/0/rpms/rubygem-sqlite3-ruby/watchers

Thx. I probably knew this at some point, but I'll forget it again as long as it is not available from UI :blush:

Maintainers can remove themselves from packages. Can you share why you would like this to be something infra does rather than the maintainers themselves when they see fit?

When we retire package, we should remove everybody from the package. In PkgDB days, everybody was removed from the Rawhide maintainers list. We can't do this now, because people probably want to maintain the older branches. But when the oldest branch becomes EOL, we should remove everybody.

I think this is very important for several reasons:

1. It is better visible that nobody is going to touch the package.
2. It is visible that maintainer really maintains something.

For example looking at [1], it might look that Joe is maintaining one package, but does he? He certainly doesn't, because the package is long gone. Also the stats for the other maintainers associated with the package in the list above are skewed.

This needs to be discussed on devel list and worked through FESCO as it is an engineering policy. There is too many 'well I don't want that' one-offs and Infrastructure can not say if any of them are a 'majority' or not.

Honestly I don't believe there is anything to discuss. This used to work in PkgDB days and we lost the functionality due to technical limitations when moved to Pagure.

The work to implement this needs to be prioritized at the cost of other work which will have to be dropped. So there needs to be a discussion on:

1. Is the functionality really needed and why?
2. What happens if it is not implemented?
3. Who will code such functionality and where?
4. Would the functionality come for 'free' if we moved to something else in the build stack.
5. What does it cost to create this functionality in time, personnel and resources
6. What has to be given up to make it happen?
7. Various other questions that probably need to be added.

These sorts of things need to be answered because there is a limited number of people available to code and upkeep tools. We have had too many initiatives which need teams of 20 people being done by 1-2 people in their spare time while also trying to keep up with 40 other initiatives.

It doesn't matter if this is something 'obvious' because every other of the 200 other services we are writing/running/patching in Fedora are also 'obvious' needs to some group. To make this happen, something has to not happen. That something other is also wanted by another group and they will need to be convinced that this is more important than that.

One "simple" solution for this would be a script that would run daily or weekly, query PDC for all the packages, find the ones that are fully retired (active=False on all branches) and ensure they only have orphan as maintainer on dist-git then.

This topic is being discussed in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/K5V3GMFQ7AVLSXLWGRAI5CLF5ZFU54KX/ feel free to weight in, currently there doesn't seem to be an overwhelming feeling that we should change the current situation.

Asked FESCo about this: https://pagure.io/fesco/issue/2444

If FESCo agrees, we can port the script to toddlers and run it regularly.

Just out of curiosity, are groups handled by this script? Because to my knowledge, there is no way to unsubscribe group from package if only the group remains.

Because to my knowledge, there is no way to unsubscribe group from package if only the group remains.

That will not happen since the main admin will be orphan. So we should not have problem to remove either users or groups.

I've announced that we will proceed with removing co-maintainers from retired packages in: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/CTYCGFVTW3ZMZ4B234M7GHFJIJCYGJPS/

PR to the toddler that will run the process regularly: https://pagure.io/fedora-infra/toddlers/pull-request/35

I've announced that we will proceed with removing co-maintainers from retired packages in: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/CTYCGFVTW3ZMZ4B234M7GHFJIJCYGJPS/

This has now been done

We now have a toddler that is configured to run every month and do this clean up (cf https://pagure.io/fedora-infra/ansible/c/f2b6a26a5e724b597fad8faab1427973c80e9bac?branch=master )

While everything is ready, it will in fact not work 100% until pagure 5.12 is out and deployed as it will come with https://pagure.io/pagure/pull-request/4969 which will allow to remove groups from a project (amusing that we missed that before...).

So once pagure 5.12 is out the remaining things will get cleaned up.

I believe we can consider this ticket close! :)