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
