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
signature.asc
Description: PGP signature
