On Sat, Mar 15, 2025 at 05:23:54PM -0400, Jeremy Bícha wrote: > On Sat, Mar 15, 2025 at 4:34 PM Roberto C. Sánchez <robe...@debian.org> wrote: > > 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*. > 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." > 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 -- Roberto C. Sánchez
