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
I see a difference between (dis)allowing a VCS in the Vcs-* fields and
(dis)allowing maintainers to store packages in a VCS.

> We can see: The Vcs wars are over; with git there is a clear winner
True.

> and in my opinion, we should remove the possibility to use most of them
> for package maintenance.
Which is not done by restricting Vcs-* values.

> It is one additional barrier to get into package maintenance
I don't think anything mentioned here is a barrier.
Even if you imagine someone looking at the list of allowed Vcs-* values to
choose which VCS to use without any context about any of these VCSes, we
have since recently "Almost all packages in Debian that use a version
control system use Git; if you create a new package, using Git is a good
idea simply because it's the system that contributors will be familiar
with." in devref 6.2.5.2.

> 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 
The main place for this is Policy 5.6.26, not devref (I don't know what
does devref mean when saying "currently the following systems are
supported by the package tracking system").

> and whatever parses Vcs-* in debian/control should be adapted to do the 
> specified thing.
Do you mean "by dropping support for ones that are no longer allowed"?
This is code cleanup in the best case and breaking support for looking at
the relevant field in old packages in the worst one.

> Finally, we can drop the orphaned packages {cvs,mercurial}-buildpackage
> (see #1026433) and add deprecation notices in brz-debian and svn-buildpackage.
This can be done independently.

Reply via email to