Hi Peter, Am Fri, Jun 12, 2026 at 01:04:58PM +0300 schrieb Peter Pentchev: > > So I think I understand where you are coming from, and I know > you mean well :) But still, I am going to give a couple of answers to > this question :) > > First and foremost, it will cause confusion. At the very least, it will > be one more thing to think about when somebody looks at a package and > considers their options to make it better: should they ask for it to > be orphaned? Should they file an ITS? Or should they use the Debian > Commons thing (that still needs to be clearly defined)? What are > the differences, what are the pros and cons? > > For more inexperienced Debian contributors, especially those who have > not been around long enough or simply have not followed the discussions > over the past couple of years, this may be a lot of confusion :) > > Second, the additional process needs to be clearly defined first. > And from what I'm seeing in this thread, and from the way I read > the original Debian Commons thread (the one that started at > https://lists.debian.org/debian-devel/2026/05/msg00105.html), > I really am not quite certain *how* exactly taking over a package for > Debian Commons differs from salvaging it and also adding Debian Commons > as an uploader. I sincerely, truly don't understand that. > (as noted elsewhere in this thread, including by himself, Paul Gevers's > original idea is much closer to LowNMU that to the QA team) > > So... yeah. Confusion abounds :)
I agree that introducing a new process requires a clear definition. In fact, one outcome of this thread for me was that Debian Commons and the orphaning discussion should be treated separately, which is why I changed the subject line in my follow-up mails[1]. Regarding the potential confusion, I am not yet convinced that the decision process would become significantly more complicated. As I see it, somebody who encounters a package that appears to lack active maintenance has a fairly simple set of choices: * If they want to take responsibility for the package themselves, they can use the existing salvaging/adoption mechanisms. * If they do not want to maintain the package themselves but are willing to investigate the situation, collect evidence and prepare the necessary QA upload, they could use the additional process I am proposing, together with the possible criteria discussed in [1]. In this case the volunteer takes responsibility for documenting why the proposed QA action is justified rather than merely asking others to investigate the package. * If they do not want to do either of these things, they can ask the MIA team to investigate. So I see the proposed process less as an alternative to salvaging and more as an option for people who are willing to help move a package towards a maintenance status that matches reality, but who do not want to become the maintainer themselves. Hope this helps clarifying the confusion Andreas. [1] https://lists.debian.org/debian-devel/2026/06/msg00086.html -- https://fam-tille.de
