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?
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.
Since you asked: I respectfully find ITN a very bad idea.
ITS is a process where you intend to take over responsibility.
ITN is a process where you intend to put pressure on the existing
maintainer for changing their way of doing *their* maintenance.
If I am mistaken and ITN is only mild one-off contributions same a NMUs
then I fail to see a reason for simply doing a 21-day-delayed NMU.
On Wed, May 07, 2025 at 05:42:39PM +0200, Jonas Smedegaard wrote:
Since you asked: I respectfully find ITN a very bad idea.
+1
ITS is a process where you intend to take over responsibility.
ITN is a process where you intend to put pressure on the existing maintainer for changing their way of doing *their* maintenance.
If I am mistaken and ITN is only mild one-off contributions same a NMUs then I fail to see a reason for simply doing a 21-day-delayed NMU.
an 21-delayed NMU would also be inappropriate because we don't change the vcs in an NMU, however delayed.
Since you asked: I respectfully find ITN a very bad idea.
ITS is a process where you intend to take over responsibility.
ITN is a process where you intend to put pressure on the existing
maintainer for changing their way of doing *their* maintenance.
If I am mistaken and ITN is only mild one-off contributions same a NMUs
then I fail to see a reason for simply doing a 21-day-delayed NMU.
If I am mistaken and ITN is only mild one-off contributions same a NMUs
then I fail to see a reason for simply doing a 21-day-delayed NMU.
Hi Jonas,
Am Wed, May 07, 2025 at 05:42:39PM +0200 schrieb Jonas Smedegaard:
Since you asked: I respectfully find ITN a very bad idea.
I intended to ask and thank you for your clearly expressed opinion.
ITS is a process where you intend to take over responsibility.
Yes.
ITN is a process where you intend to put pressure on the existing maintainer for changing their way of doing *their* maintenance.
Before getting into that, I think it's worth asking: how do we
meaningfully differentiate between "pressure" and "help"?
One might
argue that any unsolicited help can feel like pressure--especially in a project of volunteers. But the underlying intent of ITN is to offer
support in situations where maintainers, for whatever reason, may no
longer have the capacity to care for a package, and to do so in a
respectful and transparent way.
Also, I'd suggest we speak of a "*potentially* existing maintainer"
here. In all ITN cases,
I try to verify activity through
contributors.debian.org and typically notify the MIA team if the
maintainer appears inactive.
Since I said its an experiment here are the current data
If I am mistaken and ITN is only mild one-off contributions same a NMUs then I fail to see a reason for simply doing a 21-day-delayed NMU.
As I tried to outline in the longer message you responded to, the ITN approach goes beyond what is currently described for NMUs. It often
involves broader adjustments--such as repository migration or modernisation--that don't quite fit the usual NMU expectations.
Quoting Holger Levsen (2025-05-07 18:59:27)
On Wed, May 07, 2025 at 05:42:39PM +0200, Jonas Smedegaard wrote:
Since you asked: I respectfully find ITN a very bad idea.
+1
What is your offer? To take over? No, you don't want to do an ITS.
You want to do "help" the maintainer see the light in changing their way
of working themselves, by doing a one-off non-mild "NMU" which is not an
NMU because it is not mild but invasive.
Maybe just not calling it an NMU would be a compromise?
On Wed, May 07, 2025 at 10:27:03PM +0200, Jonas Smedegaard wrote:
What is your offer? To take over? No, you don't want to do an ITS.
You want to do "help" the maintainer see the light in changing their way
of working themselves, by doing a one-off non-mild "NMU" which is not an NMU because it is not mild but invasive.
I think your reaction to this is a bit harsh. I see this ITN proposal as
a way how to handle pacakges that are effectively unmaintained, but
where one is not necessarily interested in becoming the maintainer.
Importing the package into git will make the life of almost everyone¹
who comes across this package in the future easier. Yes, it's not
exactly a NMU in the strict sense, but who cares? The package is
*abandoned*. Maybe just not calling it an NMU would be a compromise?
¹ yes I know there are people who don't (yet?) use git for maintaining
packages, and that's OK. I even have friends who do it.
If their packages are maintained, then nobody will touch it.
Hi Andreas e.a.,
[Please Cc me on replies, I'm not subscribed.]
I'm with Jonas and h01ger here: I don't think the benefits of the current ITM-prodedure are bigger than the bad side effects. And even more people voiced this opinion, e.g. @ https://wiki.debian.org/DebianMentorsFaq it says:
Please Note: Don't go e-mailing maintainers with e-mails like "Your package
looks unmaintained, I'm going to hijack your package". It helps nobody, and
ensures that you will have at least one very unhappy Debian developer. "
There's also a _reason_ we do not enforce the use of salsa for our packaging work yet. Maybe the best course of action now would be to try to get a GR on such a policy change. (Ideally after the upcoming release, of course.)
I'm with Jonas and h01ger here: I don't think the benefits of the current ITM-prodedure are bigger than the bad side effects. And even more people voiced this opinion, e.g. @ https://wiki.debian.org/DebianMentorsFaq it says:
Please Note: Don't go e-mailing maintainers with e-mails like "Your package
looks unmaintained, I'm going to hijack your package". It helps nobody, and
ensures that you will have at least one very unhappy Debian developer. "
(thanks to urbec for finding this quote.)
There's also a _reason_ we do not enforce the use of salsa for our packaging work yet.
Maybe the best course of action now would be to try to get a GR on
such a policy change. (Ideally after the upcoming release, of course.)
Looking forward to join the session on this @ DebConf25 Brest!
I think Soren and Antonio summarized what I am thinking as well. If
there are seemingly unmaintained packages and we have people who are
willing to take care of them and update/refresh them by doing
something between a small NMU and a full-scale adoption, then that is
only positive.
Why do people who object this have to resort to words like "pressure", "coercion" or "hijacking"? Seems to me you are intentionally trying to
make it sound negative by labelling, instead of discussing the main
problem of half-abandoned packages and how to enable collaboration on
them.
I think your reaction to this is a bit harsh. I see this ITN proposal as
a way how to handle pacakges that are effectively unmaintained, but
where one is not necessarily interested in becoming the maintainer.
From my point of view, orphaning would be a more forceful step--closerin spirit to a QA upload, as Holger suggested. I prefer a gentler path
that allows space for maintainers to re-engage if they wish.
the underlying intent of ITN is to offer
support in situations where maintainers, for whatever reason, may no
longer have the capacity to care for a package, and to do so in a respectful and transparent way.
What is your offer? To take over? No, you don't want to do an ITS.
Also, I'd suggest we speak of a "*potentially* existing maintainer"
here. In all ITN cases,
Can we please stop calling it an intent to NMU when it is invasive?
in spirit to a QA upload, as Holger suggested. I prefer a gentler pathI try to verify activity through
contributors.debian.org and typically notify the MIA team if the
maintainer appears inactive.
So you are talking about an ITO - intent to orphan? Or ITREAO -
intent to reveal effectively an orphan?
From my point of view, orphaning would be a more forceful step--closer
In any case, you are talking about invasive action that the current maintainer either don't care about because they don't care either way,
or that they are happy about because... they were asleep and happy that
you came by and gave them a friendly-but-firm shake?
Since I said its an experiment here are the current data
What do you want those numbers to tell us? That there is nothing
invasive about your experimental method and therefore no need to invent
new acronyms because NMU is a perfectly fine descriptor, or that your
method has show efficiency or that the victims (a.k.a. lucky targets of
your merciful attention) were statistically happy with your coercion,
or...?
Right - so if you dislike the word pressure and I dislike the reuse of
NMU for something that is not an NMU, can we agree on coercion?
ITC - Intent to coerce?
Hi!
I think Soren and Antonio summarized what I am thinking as well. If
there are seemingly unmaintained packages and we have people who are
willing to take care of them and update/refresh them by doing
something between a small NMU and a full-scale adoption, then that is
only positive.
On Wed, 7 May 2025 at 21:06, Joost van Baal-Ilić <joostvb-debian@mdcc.cx> wrote:
Hi Andreas e.a.,
[Please Cc me on replies, I'm not subscribed.]
I'm with Jonas and h01ger here: I don't think the benefits of the current ITM-prodedure are bigger than the bad side effects. And even more people voiced this opinion, e.g. @ https://wiki.debian.org/DebianMentorsFaq it says:
Please Note: Don't go e-mailing maintainers with e-mails like "Your package
looks unmaintained, I'm going to hijack your package". It helps nobody, and
ensures that you will have at least one very unhappy Debian developer. "
Why do people who object this have to resort to words like "pressure", "coercion" or "hijacking"? Seems to me you are intentionally trying to
make it sound negative by labelling, instead of discussing the main
problem of half-abandoned packages and how to enable collaboration on
them.
All the examples Andreas listed are seemingly unmaintained packages.
This is not about your packages. If some day somebody asks about your package, and you don't want it to be touched and prefer to keep your
package in the current state, you can just reply in email using one of
the suggested response examples Soren outlined.
There's also a _reason_ we do not enforce the use of salsa for our packaging
work yet. Maybe the best course of action now would be to try to get a GR on
such a policy change. (Ideally after the upcoming release, of course.)
This is not about enforcing version control or Salsa. This is about
how to handle packages that are not officially orphaned and which are
not officially being salvaged, but something in between. If the new
person (or team) putting energy in a package decides that their time
is more efficiently spent when version control is utilized, it is just
a side effect of it, and it happens after the original maintainer has
had a chance to object to other people touching the package.
again, orphaning means doing a QA upload. a gentler path would be an NMU. again, I don't why we need a new process here.Orphaning is something typically done by the maintainer themselves[1].
If someone else does it unilaterally, wouldn't that come closer to a
hijack?
Would it feel more appropriate if I called it ITO (Intent to Orphan)
instead of ITN and use the 21 days waiting period + upload to
delayed=10?
I think your reaction to this is a bit harsh. I see this ITN proposal as
a way how to handle pacakges that are effectively unmaintained, but
where one is not necessarily interested in becoming the maintainer.
we have a procedure for this. orphan the package, do an QA upload.
On Thu, May 08, 2025 at 10:00:10AM +0200, Andreas Tille wrote:
From my point of view, orphaning would be a more forceful step--closerin spirit to a QA upload, as Holger suggested. I prefer a gentler path
that allows space for maintainers to re-engage if they wish.
again, orphaning means doing a QA upload. a gentler path would be an NMU. again, I don't why we need a new process here.
Hi Jonas,
Am Wed, May 07, 2025 at 10:27:03PM +0200 schrieb Jonas Smedegaard:
the underlying intent of ITN is to offer
support in situations where maintainers, for whatever reason, may no longer have the capacity to care for a package, and to do so in a respectful and transparent way.
What is your offer? To take over? No, you don't want to do an ITS.
The offer is: fixed bugs, modernised packaging, and migration to
Salsa--at no cost to the current maintainer.
In fact, I've heard from
several maintainers that they weren't sure how to migrate to Salsa, so
this can be a helpful nudge rather than a takeover.
Just for context: I've filed 33 ITS bugs so far, so ITN is not a
substitute for salvage--it's what I resort to only when an ITS doesn't
seem appropriate or feasible.
I try to verify activity through
contributors.debian.org and typically notify the MIA team if the maintainer appears inactive.
So you are talking about an ITO - intent to orphan? Or ITREAO -
intent to reveal effectively an orphan?
From my point of view, orphaning would be a more forceful step--closerin spirit to a QA upload, as Holger suggested. I prefer a gentler path
that allows space for maintainers to re-engage if they wish.
In any case, you are talking about invasive action that the current maintainer either don't care about because they don't care either way,
or that they are happy about because... they were asleep and happy that
you came by and gave them a friendly-but-firm shake?
I appreciate the irony--it's a fair push to reflect on how such actions
might be perceived. The goal is definitely not to shake people awake,
but to give room for engagement before a package is silently left to
rot. That said, tone and framing do matter, and I'm very open to
adjusting both.
I'd prefer to avoid terms that presume bad faith or intention. The whole point of this discussion is to find a name that honestly reflects the
purpose without being misleading or inflammatory. I'm still hoping we
can agree on something neutral that signals both intent and
openness--without framing it as a hostile act.
Do you personally agree that there is a problem to be addressed, and are
you mainly unhappy with my attempt at a solution, with the name I picked
for it--or both?
Thank you for your open words in any case and looking forward to see
you in Brest
Well we don't?I think your reaction to this is a bit harsh. I see this ITN proposal as >> > > a way how to handle pacakges that are effectively unmaintained, butwe have a procedure for this. orphan the package, do an QA upload.
where one is not necessarily interested in becoming the maintainer.
oh, come on: https://wiki.debian.org/qa.debian.org/MIATeam
just because one doesn't like what we have, we still have that procedure.
On May 8, 2025 04:27, Jonas Smedegaard <jonas@jones.dk> wrote:
What do you want those numbers to tell us? That there is nothing
invasive about your experimental method and therefore no need to invent
new acronyms because NMU is a perfectly fine descriptor, or that your
method has show efficiency or that the victims (a.k.a. lucky targets of
your merciful attention) were statistically happy with your coercion,
or...?
I found this paragraph very much out of line. Have you conaidered that maybe the "victims" may in fact very much appreciate the help that is offered?
It is with this kind of very unwanted attitude that we keep harmful strong package ownership in Debian.
I support Andreas work, and anyone attempting NMU, espcially considering this hostile atmosphere maintained by a small minority of us.
On Thu, May 08, 2025 at 10:26:08AM +0200, Andreas Tille wrote:
again, orphaning means doing a QA upload. a gentler path would be an NMU. again, I don't why we need a new process here.Orphaning is something typically done by the maintainer themselves[1].
that is true and it's also true that orphaning is typically done by
someone else as part of an QA upload.
If someone else does it unilaterally, wouldn't that come closer to a hijack?
right, one should not orphan without consent of the maintainer or the MIA team.
here are 101 packages waiting for an upload setting the maintainer
to the QA team:
https://qa.debian.org/orphaned.html
Would it feel more appropriate if I called it ITO (Intent to Orphan) instead of ITN and use the 21 days waiting period + upload to
delayed=10?
IMO it would certainly feel appropriate to use *existing processes*
instead of inventing new ones *and* excercising them on the archive immediatly prior to wider discussion.
I agree with using existing processes and I also appreciate Andreas' initiative to improve the state of long-neglected packages.
I believe the ITN name is a bit redundant, since our NMU process with
an upload to a delayed queue already signals an intention ahead of the
change (i.e. getting the updated package accepted to the archive)
happening.
Slightly expanding the NMU process scope would be sufficient to handle
such more intrusive changes, since we just need to cover a bigger
*update* from a *non-maintainer*.
Fixing cosmetic issues or changing the packaging style in NMUs is discouraged.
Using NMUs to make changes that are likely to be non-consensual is discouraged.
*I suggest adding a new
recommendation to the developers-reference to upload bigger NMUs to DELAYED/15.
As I understand, Andreas did not aim for orphaning the packages, just offering a bigger one-off help to the maintainer and it is reasonable
to give maintainers longer time to respond in such cases. As I recall
Andeas migrated one of my sadly neglected packages to Salsa in an NMU
and I was (and still am) thankful for that.
Other NMUs: 10 days
Other NMUs: 10 days to 28 days, depending on the changes
The developers-reference has this sentence:
Fixing cosmetic issues or changing the packaging style in NMUs is discouraged.
Maybe it could be changed to:
Using NMUs to make changes that are likely to be non-consensual is discouraged.
That would allow for changes such as upgrading the packaging style from traditional debhelper to dh.
On 08/05/25 at 16:56 +0200, Blint Rczey wrote:
I agree with using existing processes and I also appreciate Andreas' initiative to improve the state of long-neglected packages.
I believe the ITN name is a bit redundant, since our NMU process with
an upload to a delayed queue already signals an intention ahead of the change (i.e. getting the updated package accepted to the archive) happening.
Slightly expanding the NMU process scope would be sufficient to handle
such more intrusive changes, since we just need to cover a bigger
*update* from a *non-maintainer*.
I agree
The developers-reference has this sentence:
Fixing cosmetic issues or changing the packaging style in NMUs is discouraged.
Maybe it could be changed to:
Using NMUs to make changes that are likely to be non-consensual is discouraged.
Le Thu, May 08, 2025 at 08:24:57PM +0200, Lucas Nussbaum a crit :
On 08/05/25 at 16:56 +0200, Blint Rczey wrote:
I agree with using existing processes and I also appreciate Andreas' initiative to improve the state of long-neglected packages.
I believe the ITN name is a bit redundant, since our NMU process with
an upload to a delayed queue already signals an intention ahead of the change (i.e. getting the updated package accepted to the archive) happening.
Slightly expanding the NMU process scope would be sufficient to handle such more intrusive changes, since we just need to cover a bigger *update* from a *non-maintainer*.
I agree
The developers-reference has this sentence:
Fixing cosmetic issues or changing the packaging style in NMUs is discouraged.
Maybe it could be changed to:
Using NMUs to make changes that are likely to be non-consensual is discouraged.
The point of this sentence is to define what is non-consensual in the
first place. Changing the packaging style means the NMU diff will be difficult to review.
The point of this sentence is to define what is non-consensual in the
first place. Changing the packaging style means the NMU diff will be difficult to review.
It don't think that it's about the ability to review the diff.
If a NMU involves changing the packaging style _and_ making other changes, it's also possible to publish the changes somewhere as a serie of patches rather than as a single patch.
Am Thu, May 08, 2025 at 09:56:47PM +0200 schrieb Lucas Nussbaum:
The point of this sentence is to define what is non-consensual in the first place. Changing the packaging style means the NMU diff will be difficult to review.
It don't think that it's about the ability to review the diff.
The goal of the Bug of the Day initiative--through which the mentioned
NMUs were prepared--is to reduce packaging smells[1], which are:
1. Debhelper compatibility level: lower than 9 is a smell (we set 13)
2. Build system: not using dh is a smell.
3. Source format and patch system: not using 3.0 is a smell
4. VCS: not using Git and Salsa is a smell (except if the package is using dgit).
If a NMU involves changing the packaging style _and_ making other changes, it's also possible to publish the changes somewhere as a serie of patches rather than as a single patch.
Fixing item 4 provides a well-known and convenient way to publish all patches, along with build logs automatically generated by Salsa CI.
On 09/05/25 at 06:10 +0200, Andreas Tille wrote:
Am Thu, May 08, 2025 at 09:56:47PM +0200 schrieb Lucas Nussbaum:
The point of this sentence is to define what is non-consensual in the first place. Changing the packaging style means the NMU diff will be difficult to review.
It don't think that it's about the ability to review the diff.
The goal of the Bug of the Day initiative--through which the mentioned
NMUs were prepared--is to reduce packaging smells[1], which are:
1. Debhelper compatibility level: lower than 9 is a smell (we set 13)
2. Build system: not using dh is a smell.
3. Source format and patch system: not using 3.0 is a smell
4. VCS: not using Git and Salsa is a smell (except if the package is using dgit).
If a NMU involves changing the packaging style _and_ making other changes,
it's also possible to publish the changes somewhere as a serie of patches rather than as a single patch.
Fixing item 4 provides a well-known and convenient way to publish all patches, along with build logs automatically generated by Salsa CI.
I'm obviously a bit biaised since I authored trends.debian.net and thus arbitrarily decided of that list of « smells ». I agree with you that the first three items are things that it is reasonable to fix in an NMU
(except in special cases, for example if the package is team-maintained,
and the the team standardizes on using cdbs or source format 1.0).
However, I have doubts about (4), since there's still so many different workflows to use Git+Salsa.
Also, while (1-3) are things that can be worked on, sent to DELAYED/x,
and cancelled if the maintainer disagrees, one cannot really do the same
with switching to Git.
I find it smelly when a team-maintained package lacks individuals within
that team being responsible for the package, and worry if pushing smelly lone-hero-maintained packages to be team-maintained just shifts the
flavor of smells.
@Lucas: Since you are apparently the judge on odours in Debian, would
you find it sensible to introduce tracking of team-maintained packages
where most recent uploads were done by non-Uploaders?
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.
So whatever you call your intention here I guess we should see it with welcoming eyes. But, if one feels ITN can be somewhat misleading, let's
just try something else: ITR (Intent to Revamp)?
"to change or arrange something again, in order to improve it"
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.
Like Jonas I really don't think re-use of 'NMU' is appropriate here.
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.
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'.
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.
'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.
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.
ITM Modernise ITU Update
ITR Revamp
move-to-collective-maintainership (failing to think a good short name here - maybe:)
ITC Collectivise ?
ITPM Publically Maintain
The move from archive to git+salsa is significant and whilst it _is_ >reversible that would be work
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.
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
https://qa.debian.org/orphaned.html
<br><a href="https://qa.debian.org/orphaned.html" rel="noreferrer noreferrer" target="_blank">https://qa.debian.org/orphaned.html</a><br> <br>
On Thu, May 08, 2025 at 08:06:03AM +0000, Holger Levsen wrote:
Well we don't?I think your reaction to this is a bit harsh. I see this ITN proposal as a way how to handle pacakges that are effectively unmaintained, butwe have a procedure for this. orphan the package, do an QA upload.
where one is not necessarily interested in becoming the maintainer.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 153:03:53 |
| Calls: | 10,383 |
| Files: | 14,054 |
| Messages: | 6,417,828 |