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