On Fri, Jun 05, 2026 at 10:15:46PM +0200, Andreas Tille wrote:
I still think that formally orphaning unmaintained but not formally orphaned packages is the best thing (when they can't/shouldn't be RMed) because it's the only thing that explicitly marks a package as orphaned, i.e. that nobody cares about it. Shoving them into Debian Commons is not better than shoving them into random teams as was done before: it still hides their status, adds some busywork and prevents them from being formally orphaned for some more years.I personally see a difference between the QA team and Debian Commons, but even if we assume for the sake of discussion that moving the package to the QA team would be preferable in this particular case, what process would you suggest to formally orphan the package under the current circumstances? For clucene-core we have a maintainer who has not uploaded in nearly ten years, contact attempts that went unanswered, repeated NMUs, and pending fixes from contributors. Yet, as far as I understand, there is currently no established procedure that would allow the package to become formally orphaned without active involvement from the maintainer. This is exactly the gap I am trying to discuss. If we believes that such packages should become formally orphaned rather than move to Debian Commons, what is the practical path to achieve that?
Sure.Discussing a process to orphan someone else's packages (which, even to my knowledge, was asked for multiple times as a better alternative to adhoc processes such as ITS hijacking) would be better IMO but that's not what you asked :)
My personal opinion is that it should be similar to ITS in principle but with (much) tighter requirements for package eligibility and (not too much) longer timelines for the process. And with a thicker skin for the submitter.
Debian already has contributors willing to maintain such packages. The question is how we can provide a clear and scalable path for those contributors to assume ongoing responsibility when traditional single-maintainer maintenance has effectively become inactive.Don't we have a mechanism where a specific really existing person can become a maintainer of an unmaintained but not formally orphaned package directly?That would be ITS. Any volunteer(s)?
(restoring the context) you said there are volunteers, that's why I pointed to ITS. If there are no volunteers, that's a different matter than what you said.
-- WBR, wRAR
signature.asc
Description: PGP signature
