Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?

[Roberto C. Sánchez]

Question: Should uncoordinated NMUs unilaterally choose Salsa as the VCS
for a package?

I ask because one of my packages was NMUed earlier today. I have listed
myself in the LowThresholdNmu wiki page (that is, any packages for which
I am the sole maintainer). However, I did not think that placing myself
on that list meant anything other than "if you want to NMU one of my
packages, you can do so without coordination or delay, but still
otherwise observing the accepted practices for NMUS".

In this particular instance, the NMUer decided that in addition to
fixing an RC bug and another normal bug that I had not gotten around to
(which I genuinely appreciate), the NMUer also decided to do a bunch of
housekeeping, including a bunch of hygiene of files under debian/ and
also created a repo for the package in Salsa and unilaterally declared
the VCS of the package to be the new Salsa repo by populating d/control
(where the package did not have a VCS previously declared).

This appears, at least to me, to have rather substantially exceeded what
is appropriate for an uncoordinated NMU. In particular, this seems to be
inconsistent with the following paragraph from the Developer's
Reference, section 5.11.1:

* Does your NMU really fix bugs? ("Bugs" means any kind of bugs, e.g.
wishlist bugs for packaging a new upstream version, but care should
be taken to minimize the impact to the maintainer.) Fixing cosmetic
issues or changing the packaging style in NMUs is discouraged.

I had thought of possibly suggesting an update to the documentation, but
I'm not sure that adding more words would make the matter any more
clear.

How do others suggest to handle this particular situation?

Regards,

-Roberto

[Tollef Fog Heen]

]] Roberto C. Sánchez

Post by Roberto C. Sánchez
How do others suggest to handle this particular situation?

Last time it happened to me, I rolled back the inappropriate
changes in the package and let the NMUer clean up the mess left on
salsa.

-- Tollef Fog Heen UNIX is user friendly, it's just picky about
who its friends are

[Andrey Rakhmatullin]

Post by Roberto C. Sánchez
Question: Should uncoordinated NMUs unilaterally choose Salsa as the VCS
for a package?

That doesn't make sense to me, at least without context, not because
setting Vcs-* doesn't make sense in a NMU but because creating an official
package repo while not being a maintainer sounds weird.

[Jeremy Bícha]

Post by Roberto C. Sánchez
Question: Should uncoordinated NMUs unilaterally choose Salsa as the VCS
for a package?

Why are you opposed to using Salsa as the VCS for cpuset? You use
Salsa for many other packages and Github for some others.

Although there are obviously some DDs who dislike Salsa, I think the
widespread project consensus is that Salsa should be used for packages
if they are not hosted in some other VCS. Our current DPL, Andreas,
ran on an explicit platform of encouraging Salsa and has continued to
push towards that through his entire DPL term.

I consider the lack of using any VCS to be a bug, perhaps of normal
severity. And therefore, I do think it is appropriate to import a
package with its history into the Debian namespace on Salsa as part of
an NMU. The lack of a VCS makes it harder for people to contribute to
the package and makes it harder to see full packaging history.

Thank you,
Jeremy Bícha

[Roberto C. Sánchez]

Post by Jeremy Bícha

Post by Roberto C. Sánchez
Question: Should uncoordinated NMUs unilaterally choose Salsa as the VCS
for a package?

Why are you opposed to using Salsa as the VCS for cpuset? You use
Salsa for many other packages and Github for some others.

I am not opposed to using Salsa. As you note, I already use it for other
packages.

The nature of my question (which I took considerable time articulating
in order ensure that it was clear, but which apparently was not) has to
do with the appropriateness of *unilaterally* declaring Salsa as the VCS
in an *NMU*.

Post by Jeremy Bícha
Although there are obviously some DDs who dislike Salsa, I think the
widespread project consensus is that Salsa should be used for packages
if they are not hosted in some other VCS. Our current DPL, Andreas,
ran on an explicit platform of encouraging Salsa and has continued to
push towards that through his entire DPL term.

Well, yes, I am aware of all of those things. In fact, during the Mini
DebConf in Toulouse a few months ago I gave a presentation on LTS and
Andreas asked a question along the lines of "how can maintainers help to
make LTS work go more smoothly?" To which I responded along the lines
of, "host packages in Salsa and use a consistent branch structure,
preferably DEP-14". You can put me squarely in the "likes Salsa, uses
it, and encourages others to use it."

Post by Jeremy Bícha
I consider the lack of using any VCS to be a bug, perhaps of normal
severity. And therefore, I do think it is appropriate to import a
package with its history into the Debian namespace on Salsa as part of
an NMU. The lack of a VCS makes it harder for people to contribute to
the package and makes it harder to see full packaging history.

So, having established that I do not oppose using Salsa, I suppose I
ought to articulate at a finer level of detail why I have a problem with
what happened with cpuset (which your message has helpfully prompted to
think through a bit more completely).

As far as "drive by" changes go, they can be anywhere from trivial to
very substantial. Fixing a typo is trivial. Importing a package to Salsa
is substantial (though not overly so in the case of cpuset). Importing
to a VCS requires making a variety of choices (fork from upstream or
not, debian/ directory-only or not, pristine-tar or not, multiple
upstream branches or one, default branch name, etc.). And I'm sure I
left some out.

So, the point is, importing a package to a VCS, particularly one that is
then declared as the canonical VCS for that package (at least as far as
the PTS is concerned) requires making enough choices that it should be
considered off-limits in an NMU, unless the maintainer has been
coordinated with in advance.

Regards,

-Roberto

[Otto Kekäläinen]

Hi,

Post by Roberto C. Sánchez

Post by Jeremy Bícha

Post by Roberto C. Sánchez
Question: Should uncoordinated NMUs unilaterally choose Salsa as the VCS
for a package?

Why are you opposed to using Salsa as the VCS for cpuset? You use
Salsa for many other packages and Github for some others.

I am not opposed to using Salsa. As you note, I already use it for other
packages.
The nature of my question (which I took considerable time articulating
in order ensure that it was clear, but which apparently was not) has to
do with the appropriateness of *unilaterally* declaring Salsa as the VCS
in an *NMU*.

Just curious to understand what is the reason you have signed up for
https://wiki.debian.org/LowThresholdNmu ?

If you want more people to collaborate on maintaining your packages,
should you also move them to version control and preferably also host
at https://salsa.debian.org/debian/ in a namespace that is most
accessible for collaboration?

Or should we add an extra column to
https://wiki.debian.org/LowThresholdNmu where people can mark that
they want co-maintainers or NMUs but specifically want the
collaboration to be done without using version control?

[Jonas Smedegaard]

Quoting Otto KekÀlÀinen (2025-03-21 17:33:00)

Post by Otto Kekäläinen

Post by Roberto C. Sánchez

Post by Jeremy Bícha

Post by Roberto C. Sánchez
Question: Should uncoordinated NMUs unilaterally choose Salsa as the VCS
for a package?

Why are you opposed to using Salsa as the VCS for cpuset? You use
Salsa for many other packages and Github for some others.

I am not opposed to using Salsa. As you note, I already use it for other
packages.
The nature of my question (which I took considerable time articulating
in order ensure that it was clear, but which apparently was not) has to
do with the appropriateness of *unilaterally* declaring Salsa as the VCS
in an *NMU*.

Just curious to understand what is the reason you have signed up for
https://wiki.debian.org/LowThresholdNmu ?
If you want more people to collaborate on maintaining your packages,
should you also move them to version control and preferably also host
at https://salsa.debian.org/debian/ in a namespace that is most
accessible for collaboration?
Or should we add an extra column to
https://wiki.debian.org/LowThresholdNmu where people can mark that
they want co-maintainers or NMUs but specifically want the
collaboration to be done without using version control?

There is collaboration and there is cooperation.

NMUing is working on packages that someone else are responsible for,
without coordinating that work ahead of time, just informing after the
fact that the changes was done (and then being responsible for any mess
the changes might cause).

I am not Robert, but similarly have singed up for low-threshold NMUing
which I expect to mean that I permit doing narrow fixes without prior
coordination - but not restructuring of the maintenance code.

Similarly, I have messed up myself when wanting to help quickfix
packages maintained by the Rust team, because I updated upstream source
as an NMU without noticing that the Rust team do not track upstream
source as the Debian source, but instead treats the pre-packaged
distribution material from https://crates.io/ and my introducing source
from Github-released tarballs confused the build routines for the team.

Wanting and encourating collaboration does not necessarily equal wanting
Salsa-style collaboration, nor does it equal uncoordinated collaboration
(which I equate to the weaker cooperation, but I might have messed up
the terms - I am not well versed in "move fast and break things"
terminology).

- Jonas

[Otto Kekäläinen]

Post by Jonas Smedegaard
NMUing is working on packages that someone else are responsible for,
without coordinating that work ahead of time, just informing after the
fact that the changes was done (and then being responsible for any mess
the changes might cause).

Surely not "without coordinating that work ahead of time"?

Even when doing a NMU you should communicate your intent ahead. For
example https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu
recommends specifically submitting your nmudiff to the bug report and
waiting before proceeding to upload it. For those who prefer Salsa the
equivalent would be to start by submitting a Merge Request and waiting
for some time before proceeding to merge it yourself and do NMU.

Post by Jonas Smedegaard
I am not Robert, but similarly have singed up for low-threshold NMUing
which I expect to mean that I permit doing narrow fixes without prior
coordination - but not restructuring of the maintenance code.

Both https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu
and https://wiki.debian.org/LowThresholdNmu are clear about that NMUs
should fix clear bugs and not do general maintenance.

But the core of my question here was about the apparent conflict of
signing up for LowThresholdNmu as an indication that you are open for
collaboration, yet not having the package in VCS, which would make the
collaboration easier. I am trying to understand why certain people
object to using VCS while to most people I work with would not
consider doing software development without a VCS at all. Can we
improve VCS in some way to using it becomes generally accepted as a
good thing?

[Jonas Smedegaard]

Quoting Otto Kekäläinen (2025-03-21 23:14:14)

Post by Otto Kekäläinen
Even when doing a NMU you should communicate your intent ahead. For
example https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu
recommends specifically submitting your nmudiff to the bug report and
waiting before proceeding to upload it. For those who prefer Salsa the
equivalent would be to start by submitting a Merge Request and waiting
for some time before proceeding to merge it yourself and do NMU.

I assume you mean "For those who prefer using merge requests on Salsa".

Some of us (me included) prefer Salsa over Github or Sourcehut or other
forges, but what we use is its git hosting service without its optional
web-centric services (regardless if accessed via a web browser or a web
CLI tool).

Post by Otto Kekäläinen
But the core of my question here was about the apparent conflict of
signing up for LowThresholdNmu as an indication that you are open for
collaboration, yet not having the package in VCS, which would make the
collaboration easier. I am trying to understand why certain people
object to using VCS while to most people I work with would not
consider doing software development without a VCS at all. Can we
improve VCS in some way to using it becomes generally accepted as a
good thing?

I don't see a conflict there. I was interested in collaboration before
I learned to master git, and today I am interested in collaboration even
if not the same kind of collaboration that some might take for granted
as being the norm.

The way you phrase it here - collaboration in 2025 without using *any*
system for version control - I agree that it is difficult to not read
some degree of conflict into that. But if instead saying collaboration
in 2025 without playing into the norm of reducing the collaboration
style to simple statements in the package control file, then I can
easily imagine reasons for doing so that are not contradictory.
Personally I have strongly considered *removing* the hinting that the
packages that I maintain are version-controlled at Salsa, to avoid
anyone making too much assumptions on *how* I make use of Salsa and
therefore *which* kinds of collaboration I "obviously" am doing - and
I then risk having an NMU done that was notified ahead but only via
Salsa chatter which I don't follow.

Yes, you do not need to tell me that I can just disable merge requests.
I try to remember to do that - it is tedious, because they are enabled
by default and it is a lot of webby clicks to disable. I have however
experienced several times that others have then turn it on again, no
doubt by the assumption that it was disabled in error - i.e. again
assuming that collaboration on Salsa means collaboration the common
Salsa way.

I can see an efficiency benefit of streamlining towards one single way
to do collaboration in Debian. I am not convinced that the efficiency
is the only relevant quality in collaboration, however. And to me it
feels like there is a movement towards reducing variety of methods which
is driven by efficiency and does not care about other reasoning. As the
dgit project has meticulously mapped, there are many ways to use git
for Debian packaging, and on top of that there are several ways - not
only in Debian but also in the wider hacker community - of how to
collaborate around git. Some of us in Debian want to explore and
experiment and learn, not just get things done.

That was not an answer to "why not use VCS at all" but instead to what
I believe is the more appropriate question of "why not use VCS the
common way" - hope that was helpful.


- Jonas

[Holger Levsen]

Post by Jonas Smedegaard
Some of us (me included) prefer Salsa over Github or Sourcehut or other
forges, but what we use is its git hosting service without its optional
web-centric services (regardless if accessed via a web browser or a web
CLI tool).

This applies to me as well. I absolutly prefer CLI, not web. That said,
I often checkout salsa's MR via "git mr origin 123" with these two lines
in my .gitconfig:

[alias]
mr = !sh -c \"git fetch $1 merge-requests/$2/head:mr-$1-$2 && git checkout mr-$1-$2\" -


I also do comment on MRs and salsa issues via the webbrowser *and* via mail.

I also really dislike the salsa web ui. I really like salsa however.

Post by Jonas Smedegaard
I don't see a conflict there. I was interested in collaboration before
I learned to master git, and today I am interested in collaboration even
if not the same kind of collaboration that some might take for granted
as being the norm.
The way you phrase it here - collaboration in 2025 without using *any*
system for version control - I agree that it is difficult to not read
some degree of conflict into that. But if instead saying collaboration
in 2025 without playing into the norm of reducing the collaboration
style to simple statements in the package control file, then I can
easily imagine reasons for doing so that are not contradictory.
Personally I have strongly considered *removing* the hinting that the
packages that I maintain are version-controlled at Salsa, to avoid
anyone making too much assumptions on *how* I make use of Salsa and
therefore *which* kinds of collaboration I "obviously" am doing - and
I then risk having an NMU done that was notified ahead but only via
Salsa chatter which I don't follow.
Yes, you do not need to tell me that I can just disable merge requests.
I try to remember to do that - it is tedious, because they are enabled
by default and it is a lot of webby clicks to disable. I have however
experienced several times that others have then turn it on again, no
doubt by the assumption that it was disabled in error - i.e. again
assuming that collaboration on Salsa means collaboration the common
Salsa way.
I can see an efficiency benefit of streamlining towards one single way
to do collaboration in Debian. I am not convinced that the efficiency
is the only relevant quality in collaboration, however. And to me it
feels like there is a movement towards reducing variety of methods which
is driven by efficiency and does not care about other reasoning. As the
dgit project has meticulously mapped, there are many ways to use git
for Debian packaging, and on top of that there are several ways - not
only in Debian but also in the wider hacker community - of how to
collaborate around git. Some of us in Debian want to explore and
experiment and learn, not just get things done.

I very much agree with these four paragraphs.
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

"... the premise [is] that privacy is about hiding a wrong. It's not.
Privacy is an inherent human right, and a requirement for maintaining
the human condition with dignity and respect." (Bruce Schneier)

[Wookey]

Post by Otto Kekäläinen
But the core of my question here was about the apparent conflict of
signing up for LowThresholdNmu as an indication that you are open for
collaboration, yet not having the package in VCS, which would make the
collaboration easier. I am trying to understand why certain people
object to using VCS while to most people I work with would not
consider doing software development without a VCS at all.

I have been on LowThresholdNmu for many years. I am very happy for people to fix my packages.

But I don't use Salsa, or a VCS, in my packaging workflow, so people
sticking it in one on Salsa is essentially irrelevant, and a little
bit presumptive/annoying.

I know you can't understand why anyone would do this in 2025, but as
I've explained before (but you appear to have forgotten given the
above message), I am happy with the quilt-based workflow I've been
using for a very long time. I did try all that newflangled
(git/salsa/dgit) stuff a couple of years ago, but it was mostly
annoying so I went back to doing it the way I already know the runes
for.

If someone does an NMU, I expect them to tell me (by email/bug report
containing the patch and any relevant discussion). I will then (try to
remember to) update my package from the archive before doing my next
release so I don't lose their changes in a future upload. That's
it.

I'd prefer if they didn't stick it on Salsa because it's going to just
moulder and become out of date there (unless there are more NMUs than
maintainer updates). But I don't _really_ care - I probably won't even
notice (until the next person comes along and NMUs from an out-of-date
salsa repo - then I will get grumpy).

I do use VCSes for some things, just not (on the whole) debian packaging.

Post by Otto Kekäläinen
Can we
improve VCS in some way to using it becomes generally accepted as a
good thing?

I think it already is largely accepted as a good thing, but you cannot
force it everyone, as there seems to be an increasing tendency to want
to do in this project. Well you can, but if you are too annoying about
it, I'll just go an spend my time on something else - I have a very
long list...

I'll get there eventually (probably). But the pesistent drumbeat
telling me I am doing it wrong (TM) is getting a bit tiresome. I have
a working system and a corresponding body of knowledge. My packages
are generally sufficiently obscure that it's only me working on
them. It's not broken, so at least for the time being, I prefer to
spend my time on things that _do_ need fixing (I have lots of those).

I remain very happy for people to do NMUs. I appreciate their
effort. That does _not_ mean I must intrinsically want said packages
converted to an entirely different workflow. Sorry Otto :-)

Wookey

[Otto Kekäläinen]

Hi!

Post by Wookey

Post by Otto Kekäläinen
But the core of my question here was about the apparent conflict of
signing up for LowThresholdNmu as an indication that you are open for
collaboration, yet not having the package in VCS, which would make the
collaboration easier. I am trying to understand why certain people
object to using VCS while to most people I work with would not
consider doing software development without a VCS at all.

I have been on LowThresholdNmu for many years. I am very happy for people to fix my packages.
But I don't use Salsa, or a VCS, in my packaging workflow, so people

...

Post by Wookey
If someone does an NMU, I expect them to tell me (by email/bug report
containing the patch and any relevant discussion). I will then (try to
remember to) update my package from the archive before doing my next
release so I don't lose their changes in a future upload. That's
it.
I'd prefer if they didn't stick it on Salsa because it's going to just
moulder and become out of date there (unless there are more NMUs than
maintainer updates). But I don't _really_ care - I probably won't even
notice (until the next person comes along and NMUs from an out-of-date
salsa repo - then I will get grumpy).

Thanks for the explanation Wookey on why you prefer to not use VCS for
Debian packaging, and why others using VCS, and thus in Debian Salsa,
creates extra work for you. It seems it is easier for you to check if
a package has patches by searching your email and BTS than by going to
a VCS and checking what the main branch or other branches (or MRs)
have pending. I assume it is also easier for you to review and discuss
those patches, and submit new versions of patches and download and
test patches from email than it is by pulling and pushing git commits.
Just out of curiosity, what email client and plugins do you use to
achieve your optimal email-based workflow?

[G. Branden Robinson]

Post by Otto Kekäläinen
Just out of curiosity, what email client and plugins do you use to
achieve your optimal email-based workflow?

I don't see where Wookey made a claim that his workflow was "optimal",
merely that it was effective for him personally. Debian Developers are
a diverse bunch and approach packaging with a variety of techniques.

Not everyone will work exactly as another does; we shouldn't expect
that. In high-dimensional spaces, a global optimum often doesn't exist.

Regards,
Branden

[Otto Kekäläinen]

Post by G. Branden Robinson

Post by Otto Kekäläinen
Just out of curiosity, what email client and plugins do you use to
achieve your optimal email-based workflow?

I don't see where Wookey made a claim that his workflow was "optimal",
merely that it was effective for him personally. Debian Developers are
a diverse bunch and approach packaging with a variety of techniques.
Not everyone will work exactly as another does; we shouldn't expect
that. In high-dimensional spaces, a global optimum often doesn't exist.

That is why I wrote "your optimal". It was an honest question about
what setup somebody has. There is no need to start stating the obvious
about people being different.

Stating that one global optimum probably does not exist is also rather
obvious. At the same time it can still be true that for many isolated
repetitive Debian packaging tasks a global optimum can most likely be
found with some effort. Regardless if a global optimum can be achieved
or not, we need to tell new aspiring Debian Developers something when
they ask how to do things, and that advice needs to be something that
is compatible enough with everyone else to make contributions
valuable. Hence asking what workflows others have is a perfectly valid
question and a good topic for discussion.

[G. Branden Robinson]

[Summary: Let's permit ourselves to evolve, collectively _and_
individually, instead of seeking a winning workflow to freeze.]

Hi Otto,

Post by Otto Kekäläinen

Post by G. Branden Robinson

Post by Otto Kekäläinen
Just out of curiosity, what email client and plugins do you use to
achieve your optimal email-based workflow?

I don't see where Wookey made a claim that his workflow was
"optimal", merely that it was effective for him personally. Debian
Developers are a diverse bunch and approach packaging with a variety
of techniques.
Not everyone will work exactly as another does; we shouldn't expect
that. In high-dimensional spaces, a global optimum often doesn't exist.

That is why I wrote "your optimal". It was an honest question about
what setup somebody has.

I may have been too subtle in my attempt at brevity. Part of my point
is that Wookey's workflow might not be optimal _even for him_. He could
discover a tool or technique tomorrow that makes his life easier. I
think this true of practically all of us. (And it's not necessarily
the same tools or techniques that will improve each person's process.)

Post by Otto Kekäläinen
There is no need to start stating the obvious about people being
different.

I think it's worth restating when threads like

https://lists.debian.org/debian-devel/2024/07/msg00429.html

linger in recent memory.

Post by Otto Kekäläinen
Stating that one global optimum probably does not exist is also rather
obvious.

To those trained in mathematics, maybe. Many people aren't.

Post by Otto Kekäläinen
At the same time it can still be true that for many isolated
repetitive Debian packaging tasks a global optimum can most likely be
found with some effort.

"Most likely"? By what technique did you compute your P >> 0.5?

It's fine if you're personally confident that it's the case. But if you
don't support a quantitative claim, don't make one (even non-numeric
ones, like "most", "few", "always", or "never") without at least hinting
at some source of evidence usable for reaching independent conclusions.

Post by Otto Kekäläinen
Regardless if a global optimum can be achieved or not, we need to tell
new aspiring Debian Developers something when they ask how to do
things, and that advice needs to be something that is compatible
enough with everyone else to make contributions valuable. Hence asking
what workflows others have is a perfectly valid question and a good
topic for discussion.

I agree; we should encourage developers to explore and experiment with
workflows (within the boundaries of their responsibilities). It's not
necessary for each individual to focus on the search for the One
Workflow To Rule Them All; if such a thing exists, I think it will
reveal itself organically through converging preferences. Labor-saving
devices are attractors in this chaotic space.

Regards,
Branden

[Wookey]

Post by Otto Kekäläinen
Thanks for the explanation Wookey on why you prefer to not use VCS for
Debian packaging, and why others using VCS, and thus in Debian Salsa,
creates extra work for you.
Just out of curiosity, what email client and plugins do you use to
achieve your optimal email-based workflow?

Nothing fancy:
(remote) mutt, dget, mc, meld, zile/jed/emacs, uscan, tracker.debian.org, bts, the firefox 'debian' plugin, wget, sshfs/scp, quilt, dch (and sbuild/schroot, debsign, dupload to build and upload)

Wookey

[Marc Haber]

Post by Otto Kekäläinen
Just curious to understand what is the reason you have signed up for
https://wiki.debian.org/LowThresholdNmu ?
If you want more people to collaborate on maintaining your packages,
should you also move them to version control and preferably also host
at https://salsa.debian.org/debian/ in a namespace that is most
accessible for collaboration?
Or should we add an extra column to
https://wiki.debian.org/LowThresholdNmu where people can mark that
they want co-maintainers or NMUs but specifically want the
collaboration to be done without using version control?

A NMU is something else than co-maintenance. A NMU is by defintition
minimal invasive. I think that is documented somewhere.

Greetings
Marc

[Pierre-Elliott Bécue]

Post by Jeremy Bícha

Post by Roberto C. Sánchez
Question: Should uncoordinated NMUs unilaterally choose Salsa as the VCS
for a package?

Why are you opposed to using Salsa as the VCS for cpuset? You use
Salsa for many other packages and Github for some others.
Although there are obviously some DDs who dislike Salsa, I think the
widespread project consensus is that Salsa should be used for packages
if they are not hosted in some other VCS. Our current DPL, Andreas,
ran on an explicit platform of encouraging Salsa and has continued to
push towards that through his entire DPL term.
I consider the lack of using any VCS to be a bug, perhaps of normal
severity. And therefore, I do think it is appropriate to import a
package with its history into the Debian namespace on Salsa as part of
an NMU. The lack of a VCS makes it harder for people to contribute to
the package and makes it harder to see full packaging history.

Feel free to import the package in your namespace on salsa, but changing
a VCS field on a package is not something that should be done in an NMU.

I'm also on lowthresholdnmu and I'd not be happy if someone were to mess
with my workflow without asking.

Communication still is key.

Bests,

[Marco d'Itri]

Post by Roberto C. Sánchez
This appears, at least to me, to have rather substantially exceeded what
is appropriate for an uncoordinated NMU.

Indeed.

[gregor herrmann]

Post by Roberto C. Sánchez
This appears, at least to me, to have rather substantially exceeded what
is appropriate for an uncoordinated NMU. In particular, this seems to be
inconsistent with the following paragraph from the Developer's
* Does your NMU really fix bugs? ("Bugs" means any kind of bugs, e.g.
wishlist bugs for packaging a new upstream version, but care should
be taken to minimize the impact to the maintainer.) Fixing cosmetic
issues or changing the packaging style in NMUs is discouraged.

Agreed; while there are good points to be made about maintainership
and streamlining packages etc. -- under the current best practices
this is overshooting IMO.

Post by Roberto C. Sánchez
I had thought of possibly suggesting an update to the documentation, but
I'm not sure that adding more words would make the matter any more
clear.

I think the docs are okay.


Cheers,
gregor

[Andreas Tille]

Hi Robert,

Post by Roberto C. Sánchez
Question: Should uncoordinated NMUs unilaterally choose Salsa as the VCS
for a package?

I agree that *uncoordinated* NMUs should not simply choose Salsa as VCS.

Post by Roberto C. Sánchez
* Does your NMU really fix bugs? ("Bugs" means any kind of bugs, e.g.
wishlist bugs for packaging a new upstream version, but care should
be taken to minimize the impact to the maintainer.) Fixing cosmetic
issues or changing the packaging style in NMUs is discouraged.
I had thought of possibly suggesting an update to the documentation, but
I'm not sure that adding more words would make the matter any more
clear.

I'd like to stir some constructive discussion about this-hopefully
leading to a procedure that is acceptable to everyone and can be
finalized for discussion at DebCamp.

Post by Roberto C. Sánchez
How do others suggest to handle this particular situation?

I support issuing a warning before performing an NMU. These NMUs should
only apply to packages that have not been uploaded by their maintainer
for at least five years (more than two releases) and should meet
additional criteria, which I'd like to define together with your input.

If there is no response within 21 days (aligning with the ITS process
timeline), an NMU to delayed=10 based on a repository on Salsa should be
acceptable. The key rationale is to ensure that the history of NMUs is
properly recorded.


The following example brought this to my mind: The package pccts[1] has
been NMUed four times in a row, with the last maintainer upload dating
back to 2010.

I reported the maintainer to the MIA team, as this is their only package
and I have seen no activity from them. So far, I have closed five bugs
and updated the packaging to the latest standards. However, there are
still unresolved issues, and I would like to invite others to contribute
to this effort. Maintaining the package in Git would be essential to
continue this work effectively.

To address this, I opened a bug with the proposed warning[2]. What do
you think about this as a first experiment to determine what is
acceptable and what is not?

What do you think?

Kind regards
Andreas.


[1] https://tracker.debian.org/pkg/pccts
[2] https://bugs.debian.org/1100859

[Tobias Frost]

Hallo Andreas,

(this should probably go to vote as general questions for the candiates,
but I'm not having enought time right now to pursue this.)

Post by Andreas Tille
Hi Robert,

Post by Roberto C. Sánchez
Question: Should uncoordinated NMUs unilaterally choose Salsa as the VCS
for a package?

I agree that *uncoordinated* NMUs should not simply choose Salsa as VCS.

How do you define "*uncoordinated*" NMUs?
What makes it "not uncoordinated" in your view?

Post by Andreas Tille

Post by Roberto C. Sánchez
* Does your NMU really fix bugs? ("Bugs" means any kind of bugs, e.g.
wishlist bugs for packaging a new upstream version, but care should
be taken to minimize the impact to the maintainer.) Fixing cosmetic
issues or changing the packaging style in NMUs is discouraged.
I had thought of possibly suggesting an update to the documentation, but
I'm not sure that adding more words would make the matter any more
clear.

I'd like to stir some constructive discussion about this-hopefully
leading to a procedure that is acceptable to everyone and can be
finalized for discussion at DebCamp.

Andreas, the this is the correct approach. First discuss changes and
then implement them when project consensus has been reached.

Do you agree on this principle on the how to work together in Debian?

Unfortunatly1 I have to ask this question, as this is not how you and
(your|the) salvaging team is operating at the moment - IMHO.

I acknowledge, while -- after being scoulted -- the approach how to
handle ITS' by the team has changed, it continues to move or create
repos of projects it "handles" to git repos and now doing NMUs instead.
That often happens without any "coordination", for example, I've just
got a message that ddate has been moved to the debian group on salsa,
and the changelog mentions an NMU. (However, another NMU was faster and
now the repo at salsa.d.o does not reflect the package state.)
There is *no* bug report against ddate announcing any NMU, and no
nmudiff.

The move to the debian namespace changes (semantics of) maintainership,
which is bad and *not the purpose of NMUs*

The move to the debian namespace cannot be easily undone, as those repos
are protected and require an salsa admin to act on e.g for (re)moving
it.

So, do you agree that such fudamental changes to our procedure should
be discussed before? Do you think that the established rules should be
followed until then?

Post by Andreas Tille

Post by Roberto C. Sánchez
How do others suggest to handle this particular situation?

I support issuing a warning before performing an NMU. These NMUs should
only apply to packages that have not been uploaded by their maintainer
for at least five years (more than two releases) and should meet
additional criteria, which I'd like to define together with your input.
If there is no response within 21 days (aligning with the ITS process
timeline), an NMU to delayed=10 based on a repository on Salsa should be
acceptable. The key rationale is to ensure that the history of NMUs is
properly recorded.

The history of an NMU is recorded in the archives, this is the
canonical location.

Looking at nstream, currently in DELAYED/8, there is no bug report
against the package that you are NMUing, and there is no nmudiff filed
against the project. And it also moves the repository to the debian and
many changes are not addressing (filed) bugs.

(IMHO this is not within the (current) NMU procedures we have.)

Post by Andreas Tille
The following example brought this to my mind: The package pccts[1] has
been NMUed four times in a row, with the last maintainer upload dating
back to 2010.
I reported the maintainer to the MIA team, as this is their only package
and I have seen no activity from them. So far, I have closed five bugs
and updated the packaging to the latest standards. However, there are
still unresolved issues, and I would like to invite others to contribute
to this effort. Maintaining the package in Git would be essential to
continue this work effectively.

Do you think Debians approach to how being a member should be changed,
especially in the light that there are inactive members.
What changes would you think are necessary? How would you reform the MIA
procedures?

Post by Andreas Tille
To address this, I opened a bug with the proposed warning[2]. What do
you think about this as a first experiment to determine what is
acceptable and what is not?

Why do you think the procedures we have for NMUs are not sufficient?
Why do you think that you can invent an ITN without prior discussion?

Post by Andreas Tille
What do you think?
Kind regards
Andreas.
[1] https://tracker.debian.org/pkg/pccts
[2] https://bugs.debian.org/1100859
--
https://fam-tille.de

[Otto Kekäläinen]

Hi,

Post by Tobias Frost
Unfortunatly1 I have to ask this question, as this is not how you and
(your|the) salvaging team is operating at the moment - IMHO.
I acknowledge, while -- after being scoulted -- the approach how to
handle ITS' by the team has changed, it continues to move or create
repos of projects it "handles" to git repos and now doing NMUs instead.
That often happens without any "coordination", for example, I've just
got a message that ddate has been moved to the debian group on salsa,
and the changelog mentions an NMU. (However, another NMU was faster and
now the repo at salsa.d.o does not reflect the package state.)
There is *no* bug report against ddate announcing any NMU, and no
nmudiff.

This includes a bunch of accusations, so let's first check if they are
actually true. I haven't reviewed a large number of packages that have
been salvaged recently, but I did check the context for ddate[1],
pccts[2] and nstreams[3].

In the case of ddate there was a bug, and two people updated that
package on a place that was not the original version control of that
package, and neither announced their intent in the BTS either, so they
ended up doing duplicate work. It didn't have neither an TS nor NMU
email/bug report. I don't think it is fair to accuse Andreas of what
two other people did on their own, without following any process.

Only pccts and nstreams showcase what Andreas is doing, and in them he
filed Bug#1100859 and Bug#1089721, announcing his intent in advance,
which seems to me as a very thorough description and solid
communication. For nstreams the maintainer didn't reply anything, so
Andreas proceeded to move the package to the shared namespace on
Debian, where multiple people was able to collaborate on what changes
to commit before upload, and seems he then uploaded it in the DELAYED
queue for one last chance for the original maintainer to react.

What happened for ddate is unfortunate, and could maybe have been
prevented if either person working of the package had announced
something in the BTS, but I don't think it is an example of the work
of salvaging packages is currently systematically wrong or
uncoordinated or not discussed. Your reference to being scoulted
indicates that there was probably something more to this, and what you
actually experienced being wrong or unfair was perhaps left out from
the email. Thus I can't comment the bigger picture, but I would ask to
refrain from throwing out accusations on one person for trying to
create a process if the accusations are based on two other people
doing something that wasn't that process.


[1] https://tracker.debian.org/pkg/ddate
[2] https://tracker.debian.org/pkg/pccts
[3] https://tracker.debian.org/pkg/nstreams

[Jonas Smedegaard]

Quoting Otto Kekäläinen (2025-03-23 23:54:59)

Post by Otto Kekäläinen

Post by Tobias Frost
Unfortunatly1 I have to ask this question, as this is not how you and
(your|the) salvaging team is operating at the moment - IMHO.
I acknowledge, while -- after being scoulted -- the approach how to
handle ITS' by the team has changed, it continues to move or create
repos of projects it "handles" to git repos and now doing NMUs instead.
That often happens without any "coordination", for example, I've just
got a message that ddate has been moved to the debian group on salsa,
and the changelog mentions an NMU. (However, another NMU was faster and
now the repo at salsa.d.o does not reflect the package state.)
There is *no* bug report against ddate announcing any NMU, and no
nmudiff.

This includes a bunch of accusations, so let's first check if they are
actually true. I haven't reviewed a large number of packages that have
been salvaged recently, but I did check the context for ddate[1],
pccts[2] and nstreams[3].

[details snipped not disputing that NMUs occured instead of salvaging]

I find it quite relevant to raise concerns when the distinction between
NMU and slavaging gets blurred.

We have a documented process for doing non-maintainer uploads to a
package, which includes narrowly targeted changes not fundamentally
changing the way the package is maintained - even if the maintainer is
totally unresponsive.

We have a documented process for salvaging a package, which includes
the major action of taking over as maintainer even if the current
maintainer is unresponsive.

In our defined processes for NMUs and salvaging, we make sure to not
tell the maintainer how to do their work: An NMU should be narrow in
scope, and if it turns out to "blow up" then it is the responsibility
of the NMUer to fix collateral work. Salvaging puts the burden fully
in the hands of the person taking over the maintenance, who can then
restructure as they pleases, *after* the salvaging process has
completed.

I consider it an abuse of the NMU process to restructure maintenance
workflow of the package - e.g. by declaring or changing a certain use
of VCS for it. I find such abuse problematic, because it puts a burden
on the maintainer for how they ought to do their work from then on.


- Jonas

[Jonathan Dowland]

Have you had any contact with the NMUer? How has that gone?

From what I can see this is clearly an overstep and I don't think adding

any more words anywhere would make a difference. They didn't honour the
words we already have. (I note the package version is also wrong for an
NMU)

That said we all make mistakes, the NMUer is a valued member of our
community, as you are, and hopefully this can be resolved amicably.

[Andreas Tille]

This mail was sent as Message-ID: <Z-***@an3as.eu> at
Date: Mon, 24 Mar 2025 17:15:10 +0100
but never reached the list. I'm sending from a different address now
I hope forwarding from my sent folder will not break the thread.



[Some people are in CC. If you wonder why just seek for your first name.]

Hi Tobias,

please let me say in advance that I highly appreciate your work in the
MIA team and on drafting and refining the ITS procedure. That's really
great work and its extremely helpful. Since I highly evaluate your
insight into these topics I'm happy about any comment of yours like the
mail I'm now answering here (while trying not to repeat what Otto wrote
in his response).

Post by Tobias Frost
(this should probably go to vote as general questions for the candiates,
but I'm not having enought time right now to pursue this.)

I'm fine with answering on vote but I do not think that I should
actively move to this list. Anyone is kindly invited to quote me there
and ask specific questions.

Post by Tobias Frost

Post by Andreas Tille
I agree that *uncoordinated* NMUs should not simply choose Salsa as VCS.

How do you define "*uncoordinated*" NMUs?

For me uncoordinated means: Not informing the maintainer and giving a
sufficient amount of time to respond.

Post by Tobias Frost
What makes it "not uncoordinated" in your view?

Informing the maintainer by
1. Add the Maintainer ID in CC to every conversation
2. Follow the timing established in ITS procedure to enable
a sensible response time

Post by Tobias Frost

Post by Andreas Tille
I'd like to stir some constructive discussion about this-hopefully
leading to a procedure that is acceptable to everyone and can be
finalized for discussion at DebCamp.

Andreas, the this is the correct approach. First discuss changes and
then implement them when project consensus has been reached.
Do you agree on this principle on the how to work together in Debian?

I fully agree with this principle. At the same time, I think it's
important to acknowledge that, in practice, there have been cases-such
as NMUs adjusting source format to 3.0, Standards-Version updates,
debhelper compatibility level bumps, or migration from cdbs to dh-where
changes were made before a formal consensus was explicitly documented.
As we have discussed previously, NMUs have evolved beyond what is
currently reflected in the Developer's Reference, and I strongly support
updating our documentation to clarify what is considered acceptable.

That said, I believe that practical experimentation can sometimes
provide valuable insights to initiate a well-informed discussion on
complex topics. In December, we had an initial exchange on this topic
[2], and I plan to prepare something for a more structured discussion at
DebCamp. Mailing list discussions are valuable, but I think an in-person
exchange may be more productive for refining our approach.

Of course, any such experiments should be well-communicated and remain
harmless. In the case of migrating a package to a Salsa Git repository,
for example, the change is fully reversible-removing the Vcs fields is
all it takes to restore the previous state. The goal is not to impose
changes unilaterally but to explore practical steps that can lead to a
broader discussion based on existing cases.

We simply need to acknowledge that volunteer participation is fluid-some
contributors may step away without explicitly announcing it. The MIA
team does an important job of identifying and reaching out to inactive
maintainers, but this process naturally takes time. In the meantime, if
NMUs are difficult to apply, affected packages may remain blocked for
extended periods. This is not a shortcoming of the MIA team, but rather
an inherent challenge in a volunteer-driven project, where formal
transitions don't always happen in a predictable way.

Post by Tobias Frost
Unfortunatly1 I have to ask this question, as this is not how you and
(your|the) salvaging team is operating at the moment - IMHO.

We have addressed the concerns you raised about the use of the ITS
procedure in bug #1093192. In another bug report (#1094788), you
suggested using the NMU process to fix bugs. I consider the ITS
procedure to be well-crafted and highly appropriate in cases where a new
person is willing to take responsibility for maintaining a package.

The key question remains: What should be done with packages where no one
steps forward to take responsibility by adding themselves as Maintainer
or Uploader?

Please keep in mind that none of the participants in this discussion on
debian-devel are directly affected by the problem at hand. There have
been valid arguments against using Salsa for certain packages-for
example, Wookey has expressed concerns, and his viewpoint is fully
respected. However, his packages are actively maintained and do not
appear as candidates for the kind of NMU we did in the examples you
named below.

The real issue is that the people participating in this discussion are,
by definition, highly responsive. They would never let an NMU warning
period pass without responding. However, the problem lies with those who
are unresponsive-those who do not reply even after being explicitly CCed
and given 21 days notice. This creates a situation where packages
remain stuck, even when a clear process for intervention exists.

Post by Tobias Frost
I acknowledge, while -- after being scoulted -- the approach how to
handle ITS' by the team has changed, it continues to move or create
repos of projects it "handles" to git repos and now doing NMUs instead.

This is only partly true. We continue to use the ITS procedure if (and
only if) someone volunteers to add themselves as an Uploader. You
pointed out a possible misinterpretation of the ITS procedure, and we
took that feedback into account.

Post by Tobias Frost
That often happens without any "coordination", for example, I've just
got a message that ddate has been moved to the debian group on salsa,
and the changelog mentions an NMU. (However, another NMU was faster and
now the repo at salsa.d.o does not reflect the package state.)
There is *no* bug report against ddate announcing any NMU, and no
nmudiff.

You actually picked a non-fitting example. The repository was moved to a
more accessible location for the package owner, but I did not perform
the NMU. While the intention was to send a coordination mail, Bastian
(in CC) was simply faster (thank you Bastian!) in proceeding with an
actual NMU. Please do not attribute to me something that I did not do.

Regarding the future of this package, there is an open bug requesting a
new upstream version. Given that this package has had only a single
upload in over ten years and is significantly outdated, I believe it is
in the interest of our users to package the latest upstream release and
incorporate the changes already in Git[3]. If users encounter an
outdated package in Debian that has been stagnant for a decade, I wonder
where the priorities should lie. Either we acknowledge the state of such
packages and take action, or we consider their removal from Debian. Of
course, informing the maintainer about these concerns is essential.
(Sebastian as owner of ddate in CC just in case.)

Post by Tobias Frost
The move to the debian namespace changes (semantics of) maintainership,
which is bad and *not the purpose of NMUs*

I agree with your point in general, but I disagree that "maintainership"
is the right term for a package that is outdated, has open (partly RC)
bugs, and has seen only a single upload from the maintainer over ten
years ago. This seems to be a broader topic for discussion at DebCamp,
as I don't see much value in continuing this conversation here on
debian-devel.

Post by Tobias Frost
The move to the debian namespace cannot be easily undone, as those repos
are protected and require an salsa admin to act on e.g for (re)moving
it.

Another upload, with the removal of the Vcs fields, would effectively
undo the move to Salsa from a package maintenance perspective. As far as
NMU rules are concerned, I would consider myself responsible for any
unintended consequences caused by my NMU and would take the necessary
actions to address them.

Post by Tobias Frost
So, do you agree that such fudamental changes to our procedure should
be discussed before?

Yes, I agree that fundamental changes to our procedures should be
discussed beforehand. However, as I mentioned earlier, you've picked the
wrong example to make your point. I did not perform an NMU on that
package, and I would not have done so without prior coordination.

Post by Tobias Frost
Do you think that the established rules should be
followed until then?

As I mentioned earlier, while our rules are generally very effective for
the vast majority of packages, there are cases where they don't fully
serve the best interests of our users. I believe these examples can be
valuable for constructive discussions. If you feel that any of my
actions before such a discussion have been harmful in any way, I am more
than willing to fix or revert them.

Post by Tobias Frost

Post by Andreas Tille

Post by Roberto C. Sánchez
How do others suggest to handle this particular situation?

I support issuing a warning before performing an NMU. These NMUs should
only apply to packages that have not been uploaded by their maintainer
for at least five years (more than two releases) and should meet
additional criteria, which I'd like to define together with your input.
If there is no response within 21 days (aligning with the ITS process
timeline), an NMU to delayed=10 based on a repository on Salsa should be
acceptable. The key rationale is to ensure that the history of NMUs is
properly recorded.

The history of an NMU is recorded in the archives, this is the
canonical location.
Looking at nstream, currently in DELAYED/8, there is no bug report
against the package that you are NMUing, and there is no nmudiff filed
against the project. And it also moves the repository to the debian and
many changes are not addressing (filed) bugs.
(IMHO this is not within the (current) NMU procedures we have.)

I wonder if you consider #1089721 (Jörg in CC of this mail) to be
uncoordinated. The nmudiff you requested is actually the reason why
these packages should be moved to Salsa: There are complex changes
addressing several issues. These changes don't fit neatly into a
traditional nmudiff. It's the kind of work that requires Git to manage
effectively. (I do not want to repeat what Otto said in [1])

And yes, I understand your point, and I appreciate you raising it.
You're right-this is not what we traditionally understand as an NMU. We
don't have a better name for it at the moment, but I hope we can work
together on developing a new process constructively.

Post by Tobias Frost

Post by Andreas Tille
The following example brought this to my mind: The package pccts[1] has
been NMUed four times in a row, with the last maintainer upload dating
back to 2010.
I reported the maintainer to the MIA team, as this is their only package
and I have seen no activity from them. So far, I have closed five bugs
and updated the packaging to the latest standards. However, there are
still unresolved issues, and I would like to invite others to contribute
to this effort. Maintaining the package in Git would be essential to
continue this work effectively.

Do you think Debians approach to how being a member should be changed,
especially in the light that there are inactive members.

You, as an active member of the MIA team (thank you for your volunteer
work!), know that tracking down inactive members is challenging.
However, I must admit that I see your question as somewhat unrelated to
the NMU process, as an NMU does not change the maintainership of a
package. I only mentioned the MIA process in my previous mail because,
when working on the package in question, it became clear that the MIA
team should be involved.

You might say, "Contact the MIA team first, wait for confirmation, and
act later." Are you concerned that the intended NMU process could
interfere with the MIA process?

Post by Tobias Frost
What changes would you think are necessary? How would you reform the MIA
procedures?

I believe this is a topic best discussed separately. At the moment, I
don't have any specific suggestions, but I would be interested in
hearing your thoughts on potential changes.

Post by Tobias Frost

Post by Andreas Tille
To address this, I opened a bug with the proposed warning[2]. What do
you think about this as a first experiment to determine what is
acceptable and what is not?

Why do you think the procedures we have for NMUs are not sufficient?

Thank you for the question which enables me to summarise:

1. It does not fit the situation where maintainers are clearly
inactive.
2. Some changes are sufficiently complex to warrant representation in
Git.
3. Some fixes for an NMU may benefit from the collaboration of
multiple contributors, which Git facilitates.

Post by Tobias Frost
Why do you think that you can invent an ITN without prior discussion?

My aim was to experiment with a process that could stimulate a broader
discussion on how we handle certain situations in Debian. I understand
that any changes to established procedures should be discussed, but
sometimes practical experimentation is necessary to explore ideas that
may not yet be fully articulated. I firmly believe that these types of
experiments, when properly communicated and reversible, can be valuable
in generating sensible discussions about potential improvements.

Kind regards,
Andreas.

[1] https://lists.debian.org/debian-devel/2025/03/msg00524.html
[2] https://lists.debian.org/debian-devel/2024/12/msg00101.html
[3] https://salsa.debian.org/debian/ddate

[Sam Hartman]

Post by Tobias Frost
The move to the debian namespace cannot be easily undone, as
those repos are protected and require an salsa admin to act on
e.g for (re)moving it.

Andreas> Another upload, with the removal of the Vcs fields, would
Andreas> effectively undo the move to Salsa from a package
Andreas> maintenance perspective. As far as NMU rules are concerned,
Andreas> I would consider myself responsible for any unintended
Andreas> consequences caused by my NMU and would take the necessary
Andreas> actions to address them.

I do not find this response compelling.
I think having NMUs like you are talking about create and leave
dangling-but-unused repos in the debian namespace on salsa is
undesirable.
So, I disagree with the idea that simply removing the VCS headers gets
us back to the previous state.
I think that the debian namespace repo also needs to be removed.

However, I support your work even if undoing the changes is harder than
you claim it is.
I think we should have significant latitude in improving the situation
of the kind of packages you are talking about.
Please count me as someone supporting you going forward full steam
ahead.

[Andreas Tille]

Hi Sam,

Post by Sam Hartman
Andreas> Another upload, with the removal of the Vcs fields, would
Andreas> effectively undo the move to Salsa from a package
Andreas> maintenance perspective. As far as NMU rules are concerned,
Andreas> I would consider myself responsible for any unintended
Andreas> consequences caused by my NMU and would take the necessary
Andreas> actions to address them.
I do not find this response compelling.
I think having NMUs like you are talking about create and leave
dangling-but-unused repos in the debian namespace on salsa is
undesirable.
So, I disagree with the idea that simply removing the VCS headers gets
us back to the previous state.
I think that the debian namespace repo also needs to be removed.

I confirm I missed that bit. I agree that the repository should be
finally removed. I was just talking about the user visible part of the
NMU. This leaves the drawback that Salsa admins will have extra work in
the very improbable case that the repository needs to be cleaned up
later on.

Post by Sam Hartman
However, I support your work even if undoing the changes is harder than
you claim it is.
I think we should have significant latitude in improving the situation
of the kind of packages you are talking about.
Please count me as someone supporting you going forward full steam
ahead.

Thank you
Andreas.