Bug#1030382: encourage Vcs-Git over other Vcs-* headers
On Mon, Feb 20, 2023 at 01:59:21PM +, Jelmer Vernooij wrote: > I've created a PR for devref - > https://salsa.debian.org/debian/developers-reference/-/merge_requests/41 fwiw, merged into developers-reference 12.16 in sid. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ A ship is always safe at shore, but that is not what it's built for. (Albert Einstein)
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
On Mon, Feb 20, 2023 at 01:59:21PM +, Jelmer Vernooij wrote: > On Thu, Feb 09, 2023 at 02:15:42PM -0700, Sean Whitton wrote: > > Hello, > > > > On Fri 03 Feb 2023 at 05:24PM GMT, Jelmer Vernooij wrote: > > > > > Package: debian-policy > > > Severity: wishlist > > > > > > Policy currently describes Vcs-* headers as something optional, but stops > > > to > > > endorse a particular Vcs. > > > > > > At this point, it seems uncontroversial to encourage use of Vcs-Git > > > specifically here. Apart from technical arguments, it's the vcs that the > > > majority of packages in the archive uses - and thus will have the better > > > tooling, less of a learning curve for other contributors, etc. > > > > > > There are very few holdouts of other vcses in the archive. I count 62 > > > (ignoring those with an alioth URL): > > > > > > * 26 on Svn > > > * 3 on Cvs > > > * 4 on Hg (2 are hg/hg-buildpackage) > > > * 39 on bzr (half of these are actually bzr and related packages, which > > > I maintain) > > > > This strikes me as a matter for devref not Policy? > > I've created a PR for devref - > https://salsa.debian.org/debian/developers-reference/-/merge_requests/41 > > Are you saying that it doesn't belong in policy because it'd be a > recommendation rather than a must/should (at this point?), or because it's > more about the > workflow inside of Debian than package contents? Yes this is about the workflow and not the package, and so far we have let developpers pick whatever workflows suit them. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
Hello, On Mon 20 Feb 2023 at 01:59PM GMT, Jelmer Vernooij wrote: > Are you saying that it doesn't belong in policy because it'd be a > recommendation rather than a must/should (at this point?), or because it's > more about the > workflow inside of Debian than package contents? Thanks for filing the patch. As to your question, it's the latter (I'm not sure whether or not the former is true, but in any case, Policy contains recommendations in addition to musts and shoulds). -- Sean Whitton signature.asc Description: PGP signature
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
On Thu, Feb 09, 2023 at 02:15:42PM -0700, Sean Whitton wrote: > Hello, > > On Fri 03 Feb 2023 at 05:24PM GMT, Jelmer Vernooij wrote: > > > Package: debian-policy > > Severity: wishlist > > > > Policy currently describes Vcs-* headers as something optional, but stops to > > endorse a particular Vcs. > > > > At this point, it seems uncontroversial to encourage use of Vcs-Git > > specifically here. Apart from technical arguments, it's the vcs that the > > majority of packages in the archive uses - and thus will have the better > > tooling, less of a learning curve for other contributors, etc. > > > > There are very few holdouts of other vcses in the archive. I count 62 > > (ignoring those with an alioth URL): > > > > * 26 on Svn > > * 3 on Cvs > > * 4 on Hg (2 are hg/hg-buildpackage) > > * 39 on bzr (half of these are actually bzr and related packages, which I > > maintain) > > This strikes me as a matter for devref not Policy? I've created a PR for devref - https://salsa.debian.org/debian/developers-reference/-/merge_requests/41 Are you saying that it doesn't belong in policy because it'd be a recommendation rather than a must/should (at this point?), or because it's more about the workflow inside of Debian than package contents? Cheers, Jelmer
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
Hello, On Fri 03 Feb 2023 at 05:24PM GMT, Jelmer Vernooij wrote: > Package: debian-policy > Severity: wishlist > > Policy currently describes Vcs-* headers as something optional, but stops to > endorse a particular Vcs. > > At this point, it seems uncontroversial to encourage use of Vcs-Git > specifically here. Apart from technical arguments, it's the vcs that the > majority of packages in the archive uses - and thus will have the better > tooling, less of a learning curve for other contributors, etc. > > There are very few holdouts of other vcses in the archive. I count 62 > (ignoring those with an alioth URL): > > * 26 on Svn > * 3 on Cvs > * 4 on Hg (2 are hg/hg-buildpackage) > * 39 on bzr (half of these are actually bzr and related packages, which I > maintain) This strikes me as a matter for devref not Policy? -- Sean Whitton
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
On Fri, Feb 03, 2023 at 05:57:21PM +, Jelmer Vernooij wrote: > Sorry, to be clear I also meant encouraging the use of Git as a Vcs - rather > than just > of the Vcs-Git header. The Policy is a wrong place for this (and the part about Vcs-* headers is indeed a wrong place for this too).
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
On Fri, Feb 03, 2023 at 05:57:21PM +, Jelmer Vernooij wrote: > On Fri, Feb 03, 2023 at 06:48:13PM +0100, Bill Allombert wrote: > > On Fri, Feb 03, 2023 at 05:24:36PM +, Jelmer Vernooij wrote: > > > Package: debian-policy > > > Severity: wishlist > > > > > > Policy currently describes Vcs-* headers as something optional, but stops > > > to > > > endorse a particular Vcs. > > > > > > At this point, it seems uncontroversial to encourage use of Vcs-Git > > > specifically here. Apart from technical arguments, it's the vcs that the > > > majority of packages in the archive uses - and thus will have the better > > > tooling, less of a learning curve for other contributors, etc. > > > > > > There are very few holdouts of other vcses in the archive. I count 62 > > > (ignoring those with an alioth URL): > > > > > > * 26 on Svn > > > * 3 on Cvs > > > * 4 on Hg (2 are hg/hg-buildpackage) > > > * 39 on bzr (half of these are actually bzr and related packages, which > > > I maintain) > > > > I do not quite understand. Surely the package need to use the VCS-* header > > corresponding to the VCS used by the repository, whathever it is ? This is > > not > > a matter of preference. > > Sorry, to be clear I also meant encouraging the use of Git as a Vcs - rather > than just > of the Vcs-Git header. Then maybe it would be a better fit for the developer reference than to policy ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
On Fri, Feb 03, 2023 at 06:48:13PM +0100, Bill Allombert wrote: > On Fri, Feb 03, 2023 at 05:24:36PM +, Jelmer Vernooij wrote: > > Package: debian-policy > > Severity: wishlist > > > > Policy currently describes Vcs-* headers as something optional, but stops to > > endorse a particular Vcs. > > > > At this point, it seems uncontroversial to encourage use of Vcs-Git > > specifically here. Apart from technical arguments, it's the vcs that the > > majority of packages in the archive uses - and thus will have the better > > tooling, less of a learning curve for other contributors, etc. > > > > There are very few holdouts of other vcses in the archive. I count 62 > > (ignoring those with an alioth URL): > > > > * 26 on Svn > > * 3 on Cvs > > * 4 on Hg (2 are hg/hg-buildpackage) > > * 39 on bzr (half of these are actually bzr and related packages, which I > > maintain) > > I do not quite understand. Surely the package need to use the VCS-* header > corresponding to the VCS used by the repository, whathever it is ? This is not > a matter of preference. Sorry, to be clear I also meant encouraging the use of Git as a Vcs - rather than just of the Vcs-Git header. Jelmer
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
On Fri, Feb 03, 2023 at 06:43:06PM +0100, Jérémy Lal wrote: > Le ven. 3 févr. 2023 à 18:27, Jelmer Vernooij a écrit : > > > Package: debian-policy > > Severity: wishlist > > > > Policy currently describes Vcs-* headers as something optional, but stops > > to > > endorse a particular Vcs. > > > > At this point, it seems uncontroversial to encourage use of Vcs-Git > > specifically here. Apart from technical arguments, it's the vcs that the > > majority of packages in the archive uses - and thus will have the better > > tooling, less of a learning curve for other contributors, etc. > > > > There are very few holdouts of other vcses in the archive. I count 62 > > (ignoring those with an alioth URL): > > > > * 26 on Svn > > * 3 on Cvs > > * 4 on Hg (2 are hg/hg-buildpackage) > > * 39 on bzr (half of these are actually bzr and related packages, which I > > maintain) > > > > Could this remark also address the fact that in most cases, > Vcs-Git == Vcs-Browser, > and thus Vcs-Browser is irrelevant ? I do agree that it is silly to have to have to set nearly the same header for the 90% of packages that are on salsa. It does seem like an orthogonal issue and perhaps best kept separate - there are quite a few Vcs-Git headers set to something other than salsa.debian.org or github.com, which means that Vcs-Browser isn't necessarily always predictable even for Vcs-Git headers. Jelmer
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
On Fri, Feb 03, 2023 at 05:24:36PM +, Jelmer Vernooij wrote: > Package: debian-policy > Severity: wishlist > > Policy currently describes Vcs-* headers as something optional, but stops to > endorse a particular Vcs. > > At this point, it seems uncontroversial to encourage use of Vcs-Git > specifically here. Apart from technical arguments, it's the vcs that the > majority of packages in the archive uses - and thus will have the better > tooling, less of a learning curve for other contributors, etc. > > There are very few holdouts of other vcses in the archive. I count 62 > (ignoring those with an alioth URL): > > * 26 on Svn > * 3 on Cvs > * 4 on Hg (2 are hg/hg-buildpackage) > * 39 on bzr (half of these are actually bzr and related packages, which I > maintain) I do not quite understand. Surely the package need to use the VCS-* header corresponding to the VCS used by the repository, whathever it is ? This is not a matter of preference. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
Le ven. 3 févr. 2023 à 18:27, Jelmer Vernooij a écrit : > Package: debian-policy > Severity: wishlist > > Policy currently describes Vcs-* headers as something optional, but stops > to > endorse a particular Vcs. > > At this point, it seems uncontroversial to encourage use of Vcs-Git > specifically here. Apart from technical arguments, it's the vcs that the > majority of packages in the archive uses - and thus will have the better > tooling, less of a learning curve for other contributors, etc. > > There are very few holdouts of other vcses in the archive. I count 62 > (ignoring those with an alioth URL): > > * 26 on Svn > * 3 on Cvs > * 4 on Hg (2 are hg/hg-buildpackage) > * 39 on bzr (half of these are actually bzr and related packages, which I > maintain) > Could this remark also address the fact that in most cases, Vcs-Git == Vcs-Browser, and thus Vcs-Browser is irrelevant ?
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
Package: debian-policy Severity: wishlist Policy currently describes Vcs-* headers as something optional, but stops to endorse a particular Vcs. At this point, it seems uncontroversial to encourage use of Vcs-Git specifically here. Apart from technical arguments, it's the vcs that the majority of packages in the archive uses - and thus will have the better tooling, less of a learning curve for other contributors, etc. There are very few holdouts of other vcses in the archive. I count 62 (ignoring those with an alioth URL): * 26 on Svn * 3 on Cvs * 4 on Hg (2 are hg/hg-buildpackage) * 39 on bzr (half of these are actually bzr and related packages, which I maintain) Cheers, Jelmer -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-5-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled debian-policy depends on no packages. Versions of packages debian-policy recommends: ii libjs-sphinxdoc 5.3.0-3 Versions of packages debian-policy suggests: pn doc-base
