Quoting Otto Kekäläinen (2025-03-21 23:14:14) > 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). > 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 -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
