Re: ITN procedure?
Hi Jonas,
Am Wed, May 07, 2025 at 05:42:39PM +0200 schrieb Jonas Smedegaard:
>
> Since you asked: I respectfully find ITN a very bad idea.
I intended to ask and thank you for your clearly expressed opinion.
> ITS is a process where you intend to take over responsibility.
Yes.
> ITN is a process where you intend to put pressure on the existing
> maintainer for changing their way of doing *their* maintenance.
Before getting into that, I think it's worth asking: how do we
meaningfully differentiate between "pressure" and "help"? One might
argue that any unsolicited help can feel like pressure--especially in a
project of volunteers. But the underlying intent of ITN is to offer
support in situations where maintainers, for whatever reason, may no
longer have the capacity to care for a package, and to do so in a
respectful and transparent way.
Also, I'd suggest we speak of a "*potentially* existing maintainer"
here. In all ITN cases, I try to verify activity through
contributors.debian.org and typically notify the MIA team if the
maintainer appears inactive. In practice, the ITN process is only
triggered after multiple signs of long-term inactivity, and aims to
avoid sudden or disruptive changes by introducing a clear waiting
period.
Since I said its an experiment here are the current data (you can
verify the added comments in BTS / tracker.d.o):
udd=> select id, package, status from bugs where title like '%ITN%' order by ID;
id | package | status
---------+------------------------+---------
1100859 | src:pccts | done no response, last maintainer upload 2010-02-14, 5 NMUs
1101563 | src:libforms | pending no response, no action before Trixie release
1102296 | src:judy | pending Maintainer: "I am happy to move forward with the ITN process" + additional hints
1104620 | src:myspell-hy | done Maintainer: "Thanks for the help, an NMU is welcomed."
1104645 | src:display-dhammapada | pending no response, last maintainer upload 2010-03-23, 1 NMU, Request for new upstream version in 2015
1104687 | src:p910nd | pending no response, last maintainer upload 2014-11-04, Bugs: new upstream location, sysv-init script without systemd unit, FTCBFS (patch)
1104768 | src:premake4 | pending Maintainer: "Feel free to do what you need to do with it"
1104801 | src:mate-equake-applet | pending no response, maintainer did single upload in 2018-11-22, RC bug
1104828 | src:fortunes-mario | pending no response, Maintainer stepped back #847262, purpose of ITN is rather noise to find new maintainer, otherwise QA upload
(9 rows)
If you find anything in the wording--or in any of the nine cases--that
comes across as exerting pressure rather than offering help, please do
let me know. I'm more than happy to improve things where needed.
> If I am mistaken and ITN is only mild one-off contributions same a NMUs
> then I fail to see a reason for simply doing a 21-day-delayed NMU.
As I tried to outline in the longer message you responded to, the ITN
approach goes beyond what is currently described for NMUs. It often
involves broader adjustments--such as repository migration or
modernisation--that don't quite fit the usual NMU expectations.
Also just to clarify: the maximum delay is 15 days[1].
Kind regards
Andreas.
[1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#delayed-incoming
--
https://fam-tille.de
Reply to: