Re: ITN procedure?
Am Sat, May 10, 2025 at 11:20:41AM +0100 schrieb Wookey:
> On 2025-05-08 10:00 +0200, Andreas Tille wrote:
> > Am Wed, May 07, 2025 at 10:27:03PM +0200 schrieb Jonas Smedegaard:
>
> > > Can we please stop calling it an intent to NMU when it is invasive?
> >
> > You're right--"Intent To NMU" is a misleading name for this. I'd gladly
> > adopt a better term, and I appreciate any honest suggestion. Naming is
> > hard, so thanks for helping.
>
> ITM Modernise ITU Update
> ITR Revamp
> move-to-collective-maintainership (failing to think a good short name here - maybe:)
> ITC Collectivise ?
> ITPM Publically Maintain
>
> I think the underlying tension here is that this is really about
> moving the package from a strong-maintainer model to a
> collective-maintainship model, and that is still somewhat
> controversial.
ACK that this is controversial and I appreciate the thoughtful naming
suggestions--it really helps framing the discussion.
> Like Jonas I really don't think re-use of 'NMU' is appropriate here.
ACK.
> I wouldn't put it quite as strongly as he did (that seemed rather too
> aggressive, when we know Andreas is a decent chap, trying to help),
> but I agree with his points.
Thanks for the kind words. As I mentioned earlier, I believe I've
understood the arguments, and I appreciate the constructive criticism.
> The move from archive to git+salsa is significant and whilst it _is_
> reversible that would be work (and I think 'going backwards' like this
> would be disapproved-of by quite a chunk of DMs/DDs) so it's quite a
> one-way thing in practice, which is why 'NMU' (under existing rules)
> is definitely the wrong name.
>
> So long as the maintainer really is long-gone/disinterested this
> process makes sense, but if there _is_ still a willing maintainer then
> Jonas' reaction is quite right - it's a big imposition/change and definitely
> not just an 'NMU'.
The whole point of the procedure is to find an efficient way to act when
there are *multiple* signs that a maintainer is long-gone or
disinterested.
> Giving it a name that makes clear the status-change of the package
> should avoid confusion and argument.
>
> Of the various names I think 'Revamp' might actually be the best, as it avoids the value-judgement implicit in 'Update' and 'Modernise'.
> And in 10 years time it could be re-used for some other significant packaging change when we have moved on to new debates.
While "Modernise" (as also suggested by Raphael[1]) initially sounded
fine to me, I see your point about 'Revamp' avoiding value judgments.
As I mentioned before, I don't consider naming one of my strengths, so
I'm happy to go with your suggestion.
> 'Collectivise' perhaps gets to the underlying issue better, but is
> perhaps too specific to this _particular_ revamping, and would look
> silly in a decade or two when we have other issues.
This would put too much focus on moving packages to Salsa, in my
opinion. Yes, it's one part of modernising or revamping--but as I tried
to explain earlier, it was more of a precondition for doing the actual
work: demonstrating packaging improvements, asking for help, and
verifying results via Salsa CI. So, using that name would emphasize a
(perfectly welcome, but ultimately secondary) side effect.
> So yeah, please pick a better name, and be mindful that
> 'collectivising' packages is a big change, even if it feels like a
> simple 'updating' to those already in that world.
Thank you for the thoughtful reminder--I'll keep that in mind when
communicating about the process. It's easy to overlook how differently
such changes might feel depending on where people are coming from.
What's your opinion on filing 2-3 Intent to Revamp (ITR) bugs--and 2-3
Intent to Orphan (ITO) bugs where appropriate (e.g., when there's no
clear maintainer after an ITS)--over the next few weeks? Given that we're
in the freeze, no uploads would happen, and we could focus on discussing
the process with concrete examples rather than only in theory. This
could also lead to a more grounded conversation at DebCamp/DebConf. We
could retitle the relevant bugs (including existing ITNs) to reflect the
outcome of the naming and process discussion.
Kind regards
Andreas.
[1] https://lists.debian.org/debian-devel/2025/05/msg00178.html
--
https://fam-tille.de
Reply to: