Hi Phil,
Am Wed, May 07, 2025 at 08:23:08AM +0100 schrieb Phil Wyett:
> I have seen a number of bug reports over the last few days that detail an
> Intent
> To NMU (ITN) procedure. Should this not be getting proposed/discussed here?
You're absolutely right--thank you for pointing this out. The "Intent To
NMU" (ITN) tag you've seen in recent bug reports (for example, [1]) is
part of an approach I've started using experimentally, primarily in the
context of package salvage and low-activity maintenance cases. It's not
a formal process, and you are correct that it hasn't yet been proposed
for broader discussion or consensus in the Debian community.
The idea behind ITN is to provide a transparent and respectful signal
before performing an NMU--particularly in cases where a package appears
to be inactive or no longer receiving timely updates. The 21-day waiting
period before taking action, modeled after the ITS (Intent To Salvage)
process, is meant to give maintainers ample opportunity to respond while
still allowing progress when no response is forthcoming.
I fully agree that any deviation from our established NMU practices
should be discussed and, ideally, based on shared understanding. I plan
to bring a concrete proposal to the relevant lists in the near future.
In the meantime, feedback and concerns are very welcome--particularly
from those with experience in NMUs, low-maintenance packages, and
collaborative workflows.
My current motivation for experimenting with the ITN process:
1. ITS does not scale well for broader cleanup efforts
The Intent To Salvage (ITS) process rightly assumes a sustained
commitment from the person initiating it, including eventual adoption of
the package. This makes sense for individual package takeovers, but is
harder to apply when team time and resources are limited. ITN is meant
as a more lightweight mechanism for clearly unmaintained packages,
without overburdening salvage volunteers.
2. Affects de-facto orphaned packages
The affected packages have typically not seen activity from their
maintainers in ≥5 years and do not appear to be maintained in any VCS
accessible to Debian contributors (e.g. Salsa). While this is not a
policy violation, it makes collaboration and improvements significantly
harder. Collaborative maintenance--and thereby transparency--has become
an important aspect of modern Debian packaging. Specifically for
orphaned or long-unattended packages, having packaging material in a
visible, team-accessible location such as Salsa is particularly helpful.
This is not intended as a critique of active maintainers who choose a
different workflow--rather, it aims to lower barriers for shared
maintenance where the maintainer is no longer active.
3. Potential QA uploads
In many of these cases, the NMU would likely qualify as a QA upload
under existing practices. That said, it seems preferable to provide
explicit advance notice to ensure any remaining maintainers or
stakeholders are aware and have a chance to respond. The ITN bug is
intended to serve this purpose.
4. Complementing existing processes
This process is not intended to replace or undermine existing NMU or
salvage practices. Rather, it fills a specific gap: long-neglected
packages that do not meet the threshold for formal salvage, yet clearly
need attention.
5. Feedback loops and transparency
By tracking ITN actions publicly in the BTS, we create a reviewable
record and invite constructive feedback. If patterns emerge that point
to problems--too aggressive, too cautious, or otherwise--we can adjust
accordingly. This is still a learning phase.
6. This is not about punishing maintainers
The goal is not to assign blame for inactivity, but to make it easier
for others to step in when needed. Inactivity can happen for many
reasons, and this mechanism is intended to help reduce long-standing
backlog without escalating to formal processes unnecessarily.
To give another concrete example, consider #1104828 against the
fortunes-mario package. In this case, the MIA team had already filed
#847262, noting that the maintainer no longer wishes to maintain the
package. It is currently missing from testing due to a RC bug
(#1073475), which I've fixed in Git.
However, I do not intend to adopt the package myself, as it would be
better maintained by a native speaker of Portuguese. Under current NMU
guidelines, I could technically upload a fix for the RC bug. But doing
so would leave the package pointing to a Vcs-Git repository that was
archived on GitHub in 2020--meaning the canonical packaging location is
no longer usable, and any new contributions can't be committed there.
It also wouldn't feel appropriate to upload without addressing other
small but worthwhile improvements, such as updating the
Standards-Version, switching to the latest debhelper compat level, or
replacing outdated http URLs with https. Strictly speaking, these
changes go beyond what's typically allowed for an NMU, but in cases like
this, I see no strong reason to avoid them. Users are not well served
when packages remain frozen simply because the thresholds for safe
intervention are too rigid.
I'd kindly invite anyone interested in this topic to join the
to-be-announced sprint at DebCamp.
Kind regards
Andreas.
[1] https://bugs.debian.org/1104620
[2] https://bugs.debian.org/1104828
--
https://fam-tille.de
