[Changed subject] Suggestion for orphaning process (Re: Bug#879296: Maintaining potentially orphaned packages in ...)

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