Re: Reducing allowed Vcs for packaging?
On Sun, Feb 26, 2023 at 02:24:26PM +0100, Bastian Germann wrote: > During the last weeks I had a look at the Vcs situation in Debian. Currently, > there are eight possible systems allowed and one might specify several of > them for > one package. No package makes use of several Vcs references and frankly I do > not > see why this was supported in the first place. > > For the allowed systems the situation in unstable is the following: > arch is used by 2 packages pointing to bad URLs: #1025510, 1025511. > bzr is used by ~50 packages, half of which point to bad URLs. > cvs is used by 3 packages, 2 of which point to bad URLs: #1031312, #1031313. > svn is used by ~130 packages, many of which point to bad URLs. > darcs, mtn, and hg are not used. > > We can see: The Vcs wars are over; with git there is a clear winner and in my > opinion, we should remove the possibility to use most of them for package > maintenance. It is one additional barrier to get into package maintenance and > we should remove the barriers that are not necessary. What about packages that don't use a Vcs today? There are far more of those today than that are using non-standard Vcs repositories. The number of packages that's using non-standards Vcs repositories is declining gradually anyway (0.4% of the archive today). What does dropping the Vcs-* headers achieve, besides making it even harder to work with these packages? As somebody who uses Vcs-Bzr for some of the Bzr packages, I'd be on board with mandating Git (because that gets us consistency in being able to work with every package) - but I don't see the point of dropping support for other Vcs-* headers without doing that. Cheers, Jelmer
Re: Reducing allowed Vcs for packaging?
On Sun, Feb 26, 2023 at 10:25:21AM -0700, Sean Whitton wrote: > Why don't we just fix all those packacges, instead of changing any > documents? Is there anyone who actually wants to introduce new packages > not using git? I'm not so sure. mostly agreed, i'm just sure there will be very few people who want that, though for the scope of developers-reference I think those should be ignored. that said, dev-ref currently only explicitly mentions vcs-git. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The mark of a civilized man is the ability to look at a column of numbers and weep. (Bertrand Russell) signature.asc Description: PGP signature
Re: Reducing allowed Vcs for packaging?
On Sunday, 26 February 2023 17:59:52 CET Bill Allombert wrote: > > During the last weeks I had a look at the Vcs situation in Debian. > > > > For the allowed systems the situation in unstable is the following: > > ... > > svn is used by ~130 packages, many of which point to bad URLs. > > > > We can see: The Vcs wars are over; with git there is a clear winner and in > > my opinion, we should remove the possibility to use most of them for > > package maintenance. It is one additional barrier to get into package > > maintenance and we should remove the barriers that are not necessary. I have something to say about this too, but I'll do it in a P.S. as that's not the main point I want to make ... > People that use e.g. subversion could just remove the Vcs-svn field and > pretend that they do not use any VCS. What does that gain us ? I'm currently working on doing a mass-migration from (old) SVN repos to git. See https://lists.debian.org/debian-qa/2023/01/msg00031.html for details. As for this specific point: that obsolete/non-working (svn) URL are actually useful for me to figure out which need to be converted. > I have sympathy for maintainers that use the same VCS as usptream. I have > sympathy for upstream of a VCS to use that VCS instead of GIT. > > ... Unfortunately some projects I work with did not convert their whole > history to GIT and I find useful that Debian still provide subversion and > mercurial to access older commits (and dead projects history). One response to my debian-qa mail contained this: > use "gbp import-dscs" to recreate some partial history based on > snapshot.debian.org and I would not put any more effort than this. That would probably be easier/faster, but I'm hoping to (indeed) preserve all (or at least as much as possible) of the original packaging commit history. Diederik PS: I would also like that all packaging data is available on Salsa For some it's not available at all (but apparently permitted per Policy §5.6.26), which makes it hard(er then needed) if someone wants to contribute. And in other cases it's contained in an external (proprietary) system like GitHub, which is not under Debian's control. Apart from me not liking proprietary systems in general and M$ GitHub in particular, you also run the risk of things disappearing entirely without any notice and without any recourse. C.I.P. https://github.com/community/community/discussions/48173 where VundleVim (vim plugin manager) disappeared 'out of the blue'. (that vundlevim isn't packaged for Debian is irrelevant) signature.asc Description: This is a digitally signed message part.
Re: Reducing allowed Vcs for packaging?
Hello,
On Sun 26 Feb 2023 at 02:24PM +01, Bastian Germann wrote:
> Hi!
>
> During the last weeks I had a look at the Vcs situation in Debian. Currently,
> there are eight possible systems allowed and one might specify several of
> them for
> one package. No package makes use of several Vcs references and frankly I do
> not
> see why this was supported in the first place.
>
> For the allowed systems the situation in unstable is the following:
> arch is used by 2 packages pointing to bad URLs: #1025510, 1025511.
> bzr is used by ~50 packages, half of which point to bad URLs.
> cvs is used by 3 packages, 2 of which point to bad URLs: #1031312, #1031313.
> svn is used by ~130 packages, many of which point to bad URLs.
> darcs, mtn, and hg are not used.
>
> We can see: The Vcs wars are over; with git there is a clear winner and in my
> opinion, we should remove the possibility to use most of them for package
> maintenance. It is one additional barrier to get into package maintenance and
> we should remove the barriers that are not necessary.
>
> I would like to suggest removing the possibility to specify several systems
> and
> removing all systems except bzr, svn, and git, while deprecating bzr and
> possibly svn.
> This means solving the four listed bugs and convincing the cvsd maintainer to
> switch or drop the Vcs-Cvs reference. Then, the Debian Developer's Reference
> should specify the changes in §6.2.5 and whatever parses Vcs-* in
> debian/control
> should be adapted to do the specified thing.
>
> Finally, we can drop the orphaned packages {cvs,mercurial}-buildpackage
> (see #1026433) and add deprecation notices in brz-debian and svn-buildpackage.
Why don't we just fix all those packacges, instead of changing any
documents? Is there anyone who actually wants to introduce new packages
not using git? I'm not so sure.
--
Sean Whitton
signature.asc
Description: PGP signature
Re: Reducing allowed Vcs for packaging?
On Sun, Feb 26, 2023 at 02:24:26PM +0100, Bastian Germann wrote: > Hi! > > During the last weeks I had a look at the Vcs situation in Debian. Currently, > there are eight possible systems allowed and one might specify several of > them for > one package. No package makes use of several Vcs references and frankly I do > not > see why this was supported in the first place. > > For the allowed systems the situation in unstable is the following: > arch is used by 2 packages pointing to bad URLs: #1025510, 1025511. > bzr is used by ~50 packages, half of which point to bad URLs. > cvs is used by 3 packages, 2 of which point to bad URLs: #1031312, #1031313. > svn is used by ~130 packages, many of which point to bad URLs. > darcs, mtn, and hg are not used. > > We can see: The Vcs wars are over; with git there is a clear winner and in my > opinion, we should remove the possibility to use most of them for package > maintenance. It is one additional barrier to get into package maintenance and > we should remove the barriers that are not necessary. People that use e.g. subversion could just remove the Vcs-svn field and pretend that they do not use any VCS. What does that gain us ? I have sympathy for maintainers that use the same VCS as usptream. I have sympathy for upstream of a VCS to use that VCS instead of GIT. ... Unfortunately some projects I work with did not convert their whole history to GIT and I find useful that Debian still provide subversion and mercurial to access older commits (and dead projects history). Cheers, -- Bill. Imagine a large red swirl here.
Re: Reducing allowed Vcs for packaging?
Am 26.02.23 um 17:26 schrieb Adrian Bunk: I do not get your point what we would gain if the cvsd maintainer drops the Vcs-Cvs reference while continuing to maintain the package in cvs. That would be a prerequisite to drop Vcs-Cvs support. It is the last package that points to a working CVS URL.
Re: Reducing allowed Vcs for packaging?
On Sun, Feb 26, 2023 at 02:24:26PM +0100, Bastian Germann wrote: > Hi! > > During the last weeks I had a look at the Vcs situation in Debian. Currently, > there are eight possible systems allowed and one might specify several of > them for > one package. No package makes use of several Vcs references and frankly I do > not > see why this was supported in the first place. Policy §5.6.26 says it is not permitted. > For the allowed systems the situation in unstable is the following: > arch is used by 2 packages pointing to bad URLs: #1025510, 1025511. > bzr is used by ~50 packages, half of which point to bad URLs. > cvs is used by 3 packages, 2 of which point to bad URLs: #1031312, #1031313. > svn is used by ~130 packages, many of which point to bad URLs. > darcs, mtn, and hg are not used. > > We can see: The Vcs wars are over; with git there is a clear winner and in my > opinion, we should remove the possibility to use most of them for package > maintenance. It is one additional barrier to get into package maintenance and > we should remove the barriers that are not necessary. One barrier is that our work is based around tarballs and quilt, instead of using upstream git trees and commits. > I would like to suggest removing the possibility to specify several systems > and > removing all systems except bzr, svn, and git, while deprecating bzr and > possibly svn. > This means solving the four listed bugs and convincing the cvsd maintainer to > switch or drop the Vcs-Cvs reference. Then, the Debian Developer's Reference > should specify the changes in §6.2.5 and whatever parses Vcs-* in > debian/control > should be adapted to do the specified thing. Policy §5.6.26 would be the primary definition you want to change. Not using any Vcs for maintaining packages in Debian stays permitted, and I do not get your point what we would gain if the cvsd maintainer drops the Vcs-Cvs reference while continuing to maintain the package in cvs. In practice e.g. tracker.d.o seems to support Vcs-Bzr but not Vcs-Cvs, and there is no requirement for tools to drop working support for something that is no longer specified. Vcs-Browser is Vcs agnostic and would stay permitted for any kind of Vcs, including ones never listed in Policy. > Thanks for any comments, > Bastian cu Adrian
Re: Reducing allowed Vcs for packaging?
On Sun, 2023-02-26 at 14:24 +0100, Bastian Germann wrote:
> Hi!
>
> During the last weeks I had a look at the Vcs situation in Debian. Currently,
> there are eight possible systems allowed and one might specify several of them
> for
> one package. No package makes use of several Vcs references and frankly I do
> not
> see why this was supported in the first place.
>
> For the allowed systems the situation in unstable is the following:
> arch is used by 2 packages pointing to bad URLs: #1025510, 1025511.
> bzr is used by ~50 packages, half of which point to bad URLs.
> cvs is used by 3 packages, 2 of which point to bad URLs: #1031312, #1031313.
> svn is used by ~130 packages, many of which point to bad URLs.
> darcs, mtn, and hg are not used.
>
> We can see: The Vcs wars are over; with git there is a clear winner and in my
> opinion, we should remove the possibility to use most of them for package
> maintenance. It is one additional barrier to get into package maintenance and
> we should remove the barriers that are not necessary.
>
> I would like to suggest removing the possibility to specify several systems
> and
> removing all systems except bzr, svn, and git, while deprecating bzr and
> possibly svn.
> This means solving the four listed bugs and convincing the cvsd maintainer to
> switch or drop the Vcs-Cvs reference. Then, the Debian Developer's Reference
> should specify the changes in §6.2.5 and whatever parses Vcs-* in
> debian/control
> should be adapted to do the specified thing.
>
> Finally, we can drop the orphaned packages {cvs,mercurial}-buildpackage
> (see #1026433) and add deprecation notices in brz-debian and svn-buildpackage.
>
> Thanks for any comments,
> Bastian
>
It does seem like the VCS wars are over--for now. Who knows what type of
situation could force our hand to use a different VCS than Git? That future is
hard to imagine but is certainly a possibility. I think I'm understanding your
point that it would make the package maintainers lives' easier, and it does
sound like some of the packages using non-Git VCS are rotting, at least in that
regard. However, I would be hesitant to remove support for the other VCS
systems.
From my experience, whenever software engineers are actively limited for
seemingly no or little gain, they tend to turn their attention elsewhere. Also,
ripping out logic to support 7 other VCS systems stifles creativity and puts us
down a one-way street. Sure, you could argue that adding that logic back in
wouldn't be hard, but then why remove it in the first place? Wouldn't it be
more prudent just to update the non-Git packages to use Git? That's going to
have to be done anyway for a lot of them (or not).
My point is, the gain doesn't seem to be larger than the possible (and not that
probable in the near future) cost. Admittedly, it's difficult to gauge the
costs of these things.
--
Sincerely,
Brian T
publickey - brianrobt@pm.me - c8f2ec48.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
Reducing allowed Vcs for packaging?
Hi!
During the last weeks I had a look at the Vcs situation in Debian. Currently,
there are eight possible systems allowed and one might specify several of them
for
one package. No package makes use of several Vcs references and frankly I do not
see why this was supported in the first place.
For the allowed systems the situation in unstable is the following:
arch is used by 2 packages pointing to bad URLs: #1025510, 1025511.
bzr is used by ~50 packages, half of which point to bad URLs.
cvs is used by 3 packages, 2 of which point to bad URLs: #1031312, #1031313.
svn is used by ~130 packages, many of which point to bad URLs.
darcs, mtn, and hg are not used.
We can see: The Vcs wars are over; with git there is a clear winner and in my
opinion, we should remove the possibility to use most of them for package
maintenance. It is one additional barrier to get into package maintenance and
we should remove the barriers that are not necessary.
I would like to suggest removing the possibility to specify several systems and
removing all systems except bzr, svn, and git, while deprecating bzr and
possibly svn.
This means solving the four listed bugs and convincing the cvsd maintainer to
switch or drop the Vcs-Cvs reference. Then, the Debian Developer's Reference
should specify the changes in §6.2.5 and whatever parses Vcs-* in debian/control
should be adapted to do the specified thing.
Finally, we can drop the orphaned packages {cvs,mercurial}-buildpackage
(see #1026433) and add deprecation notices in brz-debian and svn-buildpackage.
Thanks for any comments,
Bastian
