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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 10 May 2025 at 11:20:41 +0100, Wookey wrote:

ITM Modernise ITU Update
ITR Revamp
move-to-collective-maintainership (failing to think a good short name here - maybe:)
ITC Collectivise ?
ITPM Publically Maintain

Whichever conventional name is chosen (one of these or something else),
may I request having the bug template spell it out, rather than adding
another acronym to the set that Debian contributors are expected to
remember?

Acronyms are necessary when there is limited space available. For the
wnpp pseudo-package, we want short prefixes because we are trying to
pack other information about the package into the Subject, like this:

ITA: foobar -- C++ framework for barring each foo automatically

so that a reader of the wnpp bug page can assess whether they would be interested in contributing to foobar, from a starting point of knowing
nothing about it. And similarly for packages that fail to build from
source, if the reporter can find out from the build log how/why it fails
to build from source, it's a much better starting point to report things
like:

foobar: FTBFS: implicit declaration of "frobnicate"
foobar: FTBFS: test suite segfaults in test-foo-barrier

so, again, it's desirable to fit the term "failed to build from source"
into a small space to leave more room for context.

But for a bug filed against the affected package itself, like <https://bugs.debian.org/1104828>, we can assume that the intended
audience of that bug (the maintainers) already know what their package
does - and indeed #1104828 was reported with a much shorter name,
"ITN: fortunes-mario". This leaves plenty of space for something like:

Intent to revamp: fortunes-mario

or even spelling out what is going to happen if there is no response:

fortunes-mario: Intent to revamp packaging, move to Salsa and upload

which would give the maintainer a much better idea of how much urgency
they should or should not place on responding to the bug report - and it
would be much less reasonable for a maintainer to complain that they didn't understand what was going to happen if the subject line explicitly says
what is going to happen.

Prior art for this is that if we think the package in question should
more likely be deleted rather than being updated, we report bugs like
"foobar: Should this package be removed?" rather than having some
unwieldy acronym meaning the same thing.

The move from archive to git+salsa is significant and whilst it _is_ >reversible that would be work

(and in many cases work that needs intervention by someone with special privileges, to delete the debian/foobar or foo-team/foobar repo, so it
cannot necessarily be done by the same person who proposed the revamp)

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.

I agree with this, despite being someone who would like to see the
majority of our packages on Salsa and having co-maintainers (or at least
team members who feel like they can validly make or accept significant
changes on behalf of an inactive maintainer). I think a more collective workflow is a good thing, but it seems better for it to be something
that happens because maintainers think so too.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-05-12 18:15 +0100, Simon McVittie wrote:

Whichever conventional name is chosen (one of these or something
else), may I request having the bug template spell it out, rather than >adding another acronym to the set that Debian contributors are
expected to remember?

Intent to revamp: fortunes-mario

or even spelling out what is going to happen if there is no response:

fortunes-mario: Intent to revamp packaging, move to Salsa and upload

You are right - this (latter) is much better when it arrives in some (possibly-moved-on, probably-less-engaged-than-they-once-were) maintainer's mailbox.

Said mailbox might well not get read in the 21 days mooted if it's
been filtered into a 'debian' bucket, but given the checks for
multi-year inactivity that'll not matter most of the time.

Wookey
--
Principal hats: Debian, Wookware
http://wookware.org/

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEER4nvI8Pe/wVWh5yq+4YyUahvnkcFAmgjTVMACgkQ+4YyUahv nkfcsQ/+NF5clU8jzn7KHhQOnUXEmcKXOFG0Tq/VqEGf+rsK8hQ/g9FzQxGO6PiL qRyQ66gZDN3pZxmjcz9s6nd+R6631/VUXlseZqOF080dUtfE+LbILCUK28kCVx5h qXBgEJ8DxoFcQ6a9JJZuyY8BEnKmFm8rKeDDPQ2baKssKjL9ZfOaYUWlE6Ti0OLO ogBEwWrvAlbdTU1mhx6Nug0uMt9i4e4Uogmuf/0YtgG2frhL9A0GFxnOvKhMhtd+ fbDM/tFvN+NO9pAiiF0MwUazJjof90Vu9PrwOt055OZJhQJM9kXb+VP/Ej6rmoSm zncTt5zbY1pSgQTAEt3/Z+reeEgrWoBqnkSXCNRMmWJhoz/Haqr5f7EwN//y9pil /zxwIdBikKEqL8tzgf8uYX9mCRaIs1puGw9EdsSj072aPBNOuY56aOVgIz/CXwuq rp/VPkm0oSR0ir4aHsk1NizJE2Oa5bNr85/xXR+XrjzGqu/76jbZv5DoJC7xMJF4 QlArPpt0+UnKHS3DUrGq4ApQhnjrGwEmvIRowUb3uf+9xhoWnUi9WpQ+CIGtzVBI N7RS22AkTTOLXWKQpVLOBhZBD28aGoqCbvVPy+iQrXlKGM/XpHgcRduSB8EPaPJI dNX+25DNNWBJkpcQIw+YdPRHQkuEypwIpavVEbo5tBKZUnCzNfI=
=XGVI
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)