Re: ITN procedure - more words, fewer acronyms please?
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
Reply to: