[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ITS process as a means to orphan packages



Quoting Andreas Tille (2025-12-10 08:49:31)
> To be absolutely clear: I do not consider the ITS process a route to
> orphan packages.

Thanks for the clarification.

> 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.

The above comes across to me as a concern that ITS is supposed to be
used a lot, and if it isn't then we should consider ways to
popularize it.

Personally I do not find it a success criteria for the ITS process that
it is used a lot. I would much rather that packages did not need to
change maintainer, either because maintainers lived forever (which is
unlikely for single-person maintenance but not for team-maintenance),
or that handovers are done by less forcefull means like simply
agreeing through internal chatter to hand over, or orphan-then-adopt.

> 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.

Specifically, I think it would be bad to expand the ITS process to
cover orphaning as well. My conclusion for the above example is either
that the ITS process was initiated too hastily, or that it worked
exactly as intended :-)

What I mean by too hastily is that is smells like you initiated a
salvation process before a new maintainer had materialized: A team can
maintain a package, but can also be a way to hide lack of maintenance.

When I was involved in the Multimedia team, they had a, to be brillant
rule: Each package must have two active uploaders. That is a way to
notice if a team-maintained package is truly _maintained_ in that team,
or just lying around. I don't know if that team rule has been dropped,
or you had already found that partner - assuming, of course, that you
yourself intended to maintain the package, because obviously the ITS
process is not a tool to impose maintainership on others. Right?


> > 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.

Salvaging is a way for enthusiastic maintainers to fetch packages from
maintainers that have lost interest in them.  It is not, however, a
tool to spark interest in maintenance.

I would love that Debian had enthusiastic maintainers for all of its
packages.

I think the ITS process is the wrong tool to get to that point,
however.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: signature


Reply to: