#8600 All maintainers should be removed from retired packages eventually.
Opened 2 months ago by vondruch. Modified 2 months ago

Lets have package foo in Fedora. It is maintained in F30, F31 and Rawhide. It has the main POC 'John' and co-maintainer 'Ann'. Unfortunately, John becomes unresponsive and the package is orphaned via 'Non-responsive maintainer policy' and therefore the POC is changed to 'orphan' user. Unfortunately, nobody (including 'Ann') adopts the package in 6 weeks and the package is retired in Rawhide. 'Ann' is still maintainer, because she possibly wanted to maintain the F30 and F31 branches. As the time goes and we have F33 and F31 is going EOL, the 'Ann' should be removed from the maintainers list. And I don't thing this happens. Following are just examples of retired packages with assigned maintainers:


Also, the packages has typically more than one watcher, but unfortunately it is not possible to see who they are :/

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.

Metadata Update from @bowlofeggs:
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: src.fp.o

2 months ago

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.

Login to comment on this ticket.