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
Attachment:
publickey - brianrobt@pm.me - c8f2ec48.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature