> 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.

> 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?

Reply via email to