Re: ITS process as a means to orphan packages
Hello Andreas,
On Wed, Dec 10, 2025 at 08:49:31AM +0100, Andreas Tille wrote:
> Hi Tobias,
>
> Thank you for bringing this up again. I admit that I have over-estimated my
> capacity here. There are other things on my desk which I would have liked to
> give more attention to.
>
>
> Am Sun, Dec 07, 2025 at 01:00:08PM +0100 schrieb Tobias Frost:
> >
> > I believe this use of the ITS process is problematic.
>
> First of all: the intention to salvage the package was sincere. Due to
> some miscommunication no human maintainer was found. As the ITS process
> requires a human maintainer - which was your earlier criticism - I
> wanted to avoid misusing the process. In the case of cfi I made a
> mistake: I intended to retitle the bug first to clarify the situation
> and give the maintainer more time to respond, but I failed to do so.
> That is my responsibility, and I am sorry for it. I do not think this
> warrants describing it as a "repeated pattern", but the mistake itself
> is mine.
>
> > We’ve discussed
> > this before, so I know you are aware of the concerns [1]. In our last
> > exchange you indicated that you would follow the ITS procedure as
> > intended.
>
> Yes. Your criticism was that a human maintainer is required. Since no
> volunteer was found, I attempted to follow your advice.
I think this reverses the intended logic somewhat.
The requirement for a committed human maintainer is a precondition for
starting an ITS, not something that emerges during the process. I would
even argue that the person who intends to maintain the package afterwards
should normally be the one starting the ITS process.
The ITS must not be started without a committed human maintainer before
the process begins. This was a deliberate design choice.
I’d also like to add my view on a recurring aspect that many of your ITS
bugs seem to have in common, in the hope of explaining how I understand
the intended scope of the ITS process: the reference to the “Bug of the
Day” initiative as a trigger for ITS.
Let me be clear that I like this initiative and its goal of highlighting
low-hanging fruit, especially as described on [a]:
This project contains some short, self-contained, relatively simple tasks
to enhance the quality of Debian with the intention to integrate
newcomers into the project by doing valuable contributions in a short
time frame.
However, this focus on short, self-contained tasks is not a good match
for the ITS procedure, as salvaging a package requires a commitment over
a prolonged period of time.
[a] https://salsa.debian.org/qa/tiny_qa_tools/-/wikis/Tiny-QA-tasks
> Given this
> situation, the only correct action was to stop the salvage process -
> which I should have done by retitling the bug. Would you agree that this
> is the appropriate way to cancel the confirmed ITS process?
As you asked for my opinion: once it was clear that no maintainer was
available, the appropriate action would have been to stop the process and
close the bug.
>
> > [1] #1094788, with further discussion in private mail.
> >
> > I’m bringing this to debian-devel for broader input - both to verify
> > whether my understanding is correct and to see whether others consider
> > using the ITS process in this way (effectively as a route to orphan
> > packages) appropriate.
>
> To be absolutely clear: I do not consider the ITS process a route to
> orphan packages.
… and with this clarification, I’m sure you agree with me.
With that understanding, I would ask you to revisit #1120624.
There are several packages that have been put through ITS by you or the
Salvaging Team without a human maintainer being added. Do you intend to
resolve those in line with the defined procedure as well?
> In May we discussed how to deal with clearly dormant
> packages. My takeaway from that discussion was that we might need an
> "Intend to Orphan" step, which still requires refinement. Dealing with
> dormant packages was the explicit purpose of my BoF in Brest[3], where
> this topic was discussed in detail. The room expressed a range of
> opinions - including suggestions for shorter waiting periods and more
> active removal of long-neglected packages. A recurring theme in that
> discussion was that many people who care about the topic are already
> very busy, which may explain why the follow-up work has not materialised
> yet. I would welcome if we could form a small group to continue this and
> work out concrete proposals.
In retrospect, one reason the ITS process has worked well is that it was
discussed, consensus was reached, and only then it was implemented. I
would strongly recommend following a similar path for any "Intend to
Orphan" procedure, and that any such use be deferred until the process
itself is clearly defined.
(For the cases already completed, could you please file the corresponding
WNPP bugs, as required by the orphaning procedure?)
> > The ITS process was carefully designed [2]. While it’s not immutable
> > and can certainly be updated or improved, changes should follow prior
> > discussion and consensus. It was, however, explicitly not intended to
> > be used for orphaning packages.
>
> Fully agreed - ITS is not a mechanism for orphaning packages. When
> the intention is to orphan, that must be explicit. My mistake here was
> not making that clear in time.
> More generally, I believe the ITS process is under-used. Looking at ITS
> bugs, 230 DDs have used the process at least once, 71 have used it more
> than once[4], and only 4 have used it more than ten times. Possible
> reasons include lack of time, low visibility of the process, and its
> complexity.
I don’t think these numbers are a useful metric for measuring the success
of the ITS process. A higher number of ITS bugs does not imply better
outcomes. Success is better measured by whether the resulting package is
in a better state afterwards.
I believe that is more likely when maintainers deliberately select
packages they have an interest in and intend to care for, rather than
when packages are selected primarily through broad QA-driven criteria.
> As another example, yesterday I filed ITS #1122194 with the intention of
> moving mp3splt into the Multimedia team. During the discussion it became
> clear that removal was the more appropriate outcome. This illustrates
> that ITS can serve as a structured point for intervention, not a
> predetermined pipeline.
The Multimedia Team discussion suggests that the team was not previously
expecting or prepared for the proposed takeover. This underlines why ITS
should only be initiated once a willing maintainer or team has already
agreed to assume responsibility, rather than being used as a way to
probe or trigger that decision.
I think this bug illustrates that it is preferable to have a maintainer
deliberately select their packages. Such a selection process would
normally include analysing the package, and earlier triage would likely
have revealed that it is no longer a good fit for Debian.
> > There was some discussion about creating an Intend To Orphan (ITO)
> > procedure, but (i may have missed it) did not reach a conclusion.
> > Maybe this discussion should be restarted?
>
> Absolutely. At the DebConf BoF[3] I also sensed that many people
> see the need for a clearer process.
>
> Can you imagine a fair and workable procedure that addresses the
> reality that we have a significant number of dormant packages, while
> still ensuring that maintainers are treated respectfully and that
> consensus is maintained? I would very much welcome constructive
> suggestions on how to move forward.
I agree that dormant packages are a real and ongoing challenge for the
project, and that maintainers should always be treated respectfully.
However, I think it is important to keep this discussion scoped to the
ITS process itself. ITS was designed to address a very specific
situation: a motivated maintainer intending to take over long-term
responsibility for a package. It is not a general mechanism for dealing
with dormant packages, nor a tool to generate interest where none
currently exists.
As Jonas already pointed out, salvaging works well when it enables
enthusiastic maintainers to take over packages they care about; it is
much less effective as a way to create that enthusiasm. For broader
questions around dormant packages - including possible "Intend to
Orphan" procedures - I suggest to have a separate discussion to get
to a clearly defined process.
For the purposes of this thread, I would therefore suggest focusing on
ensuring that ITS continues to be used in line with its original scope
and design, rather than expanding its role to solve a wider set of
problems. As I've said earlier, the process is not immutable, but
changes need to be discussed prior implementation, to avoid jeopodizing
the success and acceptance of the ITS process.
--
tobi
Reply to: