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
