[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


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)

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: