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
