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. 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?
> [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. 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.
> 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.
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.
> 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.
Thanks for raising the topic again. I would welcome continued
collaboration on finding a practical path forward.
Kind regards
Andreas.
> [2] https://lists.debian.org/debian-devel/2018/07/msg00453.html
[3] https://debconf25.debconf.org/talks/2-dealing-with-dormant-packages-ensuring-debians-high-standards/
[4] udd=> select count(*) from (select submitter_email, count(*) from (select submitter_email from archived_bugs where title like '%ITS%' union all select submitter_email from bugs where title like '%ITS%') group by submitter_email) where count > 1;
count
-------
71
udd=> select count(*) from (select submitter_email, count(*) from (select submitter_email from archived_bugs where title like '%ITS%' union all select submitter_email from bugs where title like '%ITS%') group by submitter_email) where count > 10;
count
-------
4
--
https://fam-tille.de
Attachment:
signature.asc
Description: PGP signature