During the last weeks I had a look at the Vcs situation in Debian. Currently, there are eight possible systems allowedI 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 winnerTrue.
and in my opinion, we should remove the possibility to use most of themWhich is not done by restricting Vcs-* values.
for package maintenance.
It is one additional barrier to get into package maintenanceI don't think anything mentioned here is a barrier.
I would like to suggest removing the possibility to specify several systems andThe main place for this is Policy 5.6.26, not devref (I don't know what
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.Do you mean "by dropping support for ones that are no longer allowed"?
Finally, we can drop the orphaned packages {cvs,mercurial}-buildpackageThis can be done independently.
(see #1026433) and add deprecation notices in brz-debian and svn-buildpackage.
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.
Thanks for any comments,
Bastian
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.
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.
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.
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).
use "gbp import-dscs" to recreate some partial history based on snapshot.debian.org and I would not put any more effort than this.
...
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)
On Sun, Feb 26, 2023 at 07:25:57PM +0100, Diederik de Haas wrote:
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.
Perhaps tomorrow some company like Oracle decides to buy GitLab Inc.,
and then Oracle GitLab stops the current Freemium business model
effective immediately.
For anything in Debian, the package sources in Debian would not
disappear when a repository (or salsa) disappears.
Question as I don't know: is that only the package change that gets
uploaded to the Debian archive, or is there also a place where the (git) history of the changes leading up to a new upload gets stored?
On Sunday, 26 February 2023 20:06:26 CET Adrian Bunk wrote:
...
For anything in Debian, the package sources in Debian would not
disappear when a repository (or salsa) disappears.
Question as I don't know: is that only the package change that gets uploaded to the Debian archive, or is there also a place where the (git) history of the
changes leading up to a new upload gets stored?
To use an analogy: I'd like that not only the 'destination' is preserved, but also the lead up to the destination.
On Sun, Feb 26, 2023 at 09:57:34PM +0100, Diederik de Haas wrote:
On Sunday, 26 February 2023 20:06:26 CET Adrian Bunk wrote:
...
For anything in Debian, the package sources in Debian would not
disappear when a repository (or salsa) disappears.
Question as I don't know: is that only the package change that gets uploaded to the Debian archive, or is there also a place where the (git) history of the changes leading up to a new upload gets stored?
To use an analogy: I'd like that not only the 'destination' is preserved, but also the lead up to the destination.
What goes into the Debian archive is based on tarballs and quilt patches. Nothing is stored there except the files you upload.
But what do you expect to get from the git history?
There is no requirement that any history in addition to what is in
the Debian archive exists at all, or any guarantee that what is in
some git tree somewhere is actually the same as what is in the
Debian archive. And git history might just be one commit per upload.
I would rather like to see people write useful changelog entries
that will still be useful in 25 years instead of
* New upstream version (Closes: #1234567, #1234568, #1234569, ...
or
* Add R
than hoping that git metadata would contain anything more useful
than that for such packages.
Diederik de Haas <didi.debian@cknow.org> writes:
Question as I don't know: is that only the package change that gets uploaded to the Debian archive, or is there also a place where the (git) history of the changes leading up to a new upload gets stored?
dgit maintains a history of every package in Debian. If you use dgit to
make your upload, that will include the full Git history of the changes, regardless of where you store your Git repository. If you don't, then it only has the uploads to work with, so each package upload is a new commit
and the detailed breakdown of the work between those uploads is not
available via dgit.
But it does provide at least upload-level granularity as a Git history for every package, even those maintained with no version control system at
all, with the option for each package maintainer of opting into providing more.
...
The reason that I'm such a proponent of that is that 3 weeks or 3 months from now, there's a reasonable chance that you (the author/committer) does no longer remember the details of that commit.
In 3+ years that will be close to 0.
AFAIK actual mind reading does not exist, so someone else surely wouldn't know.
I've already encountered several cases where the commit was 10+ years old and the commit msg what "Disable setting X" and looking at the diff, I can see the
X was indeed disabled. But nothing more.
But now I want to enable setting X. But I have no context to know why that would be a bad idea, or actually a good idea *now*, or what will break as a consequence of my enabling X. All I can do is enable X and keep an eye out for
bug reports.
I think that's what you want to achieve with 'better' changelogs is something similar. I think the git commits are a better place as it's easier to make finer grained distinctions and it's more directly linked to the changes.
...
Cheers,
Diederik
Russ Allbery <rra@debian.org> wrote:
dgit maintains a history of every package in Debian.
AFAIK the Debian Xen Team does use dgit (not surprising given dgit's maintainer (and author?)) ... and that drives me insane.
I'm very sure that is due to me not understanding the concepts/idea/etc, but I
can't wrap my head around it and it feels *to me* like it constantly rewrites
the (git) history and then does a `git push -f` ... every time.
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.
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.
But AFAIK the Debian Xen Team does use dgit (not surprising given dgit's maintainer (and author?)) ... and that drives me insane.
I'm very sure that is due to me not understanding the concepts/idea/etc, but I
can't wrap my head around it and it feels *to me* like it constantly rewrites the (git) history and then does a `git push -f` ... every time.
I once referenced a patch by number (and a short description iirc) and on the next push, that patch had a different number, thus messing up my commit msg.
The most confusing thing for/to me is that it completely rearranges the commit
sequence, so I can't follow the changes that happened over time.
Right now in https://salsa.debian.org/xen-team/debian-xen/-/commits/master HEAD~30 (and the 2 commits before that) are the most recent (and to me the most relevant), but HEAD~9 was made 8 YEARS ago.
I may learn dgit in time, but that'll probably be a (long) while.
On Sun, Feb 26, 2023 at 09:57:34PM +0100, Diederik de Haas wrote:
On Sunday, 26 February 2023 20:06:26 CET Adrian Bunk wrote:
...
For anything in Debian, the package sources in Debian would not
disappear when a repository (or salsa) disappears.
Question as I don't know: is that only the package change that gets uploaded >> to the Debian archive, or is there also a place where the (git) history of the
changes leading up to a new upload gets stored?
To use an analogy: I'd like that not only the 'destination' is preserved, but
also the lead up to the destination.
What goes into the Debian archive is based on tarballs and quilt patches. Nothing is stored there except the files you upload.
Hello,
On Sun 26 Feb 2023 at 11:38PM +02, Adrian Bunk wrote:
On Sun, Feb 26, 2023 at 09:57:34PM +0100, Diederik de Haas wrote:
On Sunday, 26 February 2023 20:06:26 CET Adrian Bunk wrote:
...
For anything in Debian, the package sources in Debian would not
disappear when a repository (or salsa) disappears.
Question as I don't know: is that only the package change that gets uploaded
to the Debian archive, or is there also a place where the (git) history of the
changes leading up to a new upload gets stored?
To use an analogy: I'd like that not only the 'destination' is preserved, but
also the lead up to the destination.
What goes into the Debian archive is based on tarballs and quilt patches. Nothing is stored there except the files you upload.
This is a matter of perspective. The fact that dak doesn't store git histories and send them out to mirrors is an implementation detail, to
me. salsa and dgit-repos are both just as significant Debian archives,
even if they're not what we refer to when we write "Debian archive".
Sean Whitton
On Wed, Mar 01, 2023 at 05:54:38PM -0700, Sean Whitton wrote:
Hello,
Hi Sean,
On Sun 26 Feb 2023 at 11:38PM +02, Adrian Bunk wrote:
On Sun, Feb 26, 2023 at 09:57:34PM +0100, Diederik de Haas wrote:
On Sunday, 26 February 2023 20:06:26 CET Adrian Bunk wrote:
...
For anything in Debian, the package sources in Debian would not
disappear when a repository (or salsa) disappears.
Question as I don't know: is that only the package change that gets uploaded
to the Debian archive, or is there also a place where the (git) history of the
changes leading up to a new upload gets stored?
To use an analogy: I'd like that not only the 'destination' is preserved, but
also the lead up to the destination.
What goes into the Debian archive is based on tarballs and quilt patches. >> > Nothing is stored there except the files you upload.
This is a matter of perspective. The fact that dak doesn't store git
histories and send them out to mirrors is an implementation detail, to
me. salsa and dgit-repos are both just as significant Debian archives,
even if they're not what we refer to when we write "Debian archive".
for the contents of packages in the archive the ftp team requires that >everything is in the preferred form of modification.
It is therefore surprising that you as member of the ftp team declare
that there is no requirement at all that the packages themselves that
get uploaded to the archive are in the preferred form of modification
as long as the preferred form of modification is in salsa.
Maintainers are now permitted to clone the upstream git tree, take one >commit as upstream, work on top of that, and then upload this without
the kludge of pristine-tar or restrictions due to quilt.
Formats 1.0 or 3.0 (native) will be the natural formats generated for
the Debian archive.
Format 3.0 (quilt) will be another option, where a generated tarball is >uploaded as upstream source (as is already required by the ftp team for >repacks) plus one debian/patches/debian.patch containing all changes to
the upstream sources.
Generating one quilt patch per commit that changes the upstream sources
would not always be technically possible due to limitations of quilt.
for the contents of packages in the archive the ftp team requires that everything is in the preferred form of modification.
On March 4, 2023 5:25:35 PM UTC, Adrian Bunk <bunk@debian.org> wrote:
On Wed, Mar 01, 2023 at 05:54:38PM -0700, Sean Whitton wrote:
This is a matter of perspective. The fact that dak doesn't store git
histories and send them out to mirrors is an implementation detail, to
me. salsa and dgit-repos are both just as significant Debian archives,
even if they're not what we refer to when we write "Debian archive".
for the contents of packages in the archive the ftp team requires that >everything is in the preferred form of modification.
It is therefore surprising that you as member of the ftp team declare...
that there is no requirement at all that the packages themselves that
get uploaded to the archive are in the preferred form of modification
as long as the preferred form of modification is in salsa.
Putting something in a git repository doesn't make a particular file more or less the preferred form of modification. It's the same form. IMO you are conflating two separate concepts here. I don't find Sean's perspective at all surprising.
Scott K
for the contents of packages in the archive the ftp team requires that everything is in the preferred form of modification.
It is therefore surprising that you as member of the ftp team declare
that there is no requirement at all that the packages themselves that
get uploaded to the archive are in the preferred form of modification
as long as the preferred form of modification is in salsa.
On 16792 March 1977, Adrian Bunk wrote:
for the contents of packages in the archive the ftp team requires that
everything is in the preferred form of modification.
Yes. Of course.
But git or svn or even sccs and rcs is NOT, in any way, preferred for of modification. Only one way of storage and handling some metadata.
On Sat 04 Mar 2023 at 10:58PM +01, Joerg Jaspert wrote:
On 16792 March 1977, Adrian Bunk wrote:
for the contents of packages in the archive the ftp team requires that
everything is in the preferred form of modification.
Yes. Of course.
But git or svn or even sccs and rcs is NOT, in any way, preferred for of
modification. Only one way of storage and handling some metadata.
This is Debian's official position, but it's debateable.
There is the preferred form for modification for an individual *file*,
and that probably doesn't include version control. But the preferred
form for modifying a *project* arguably does.
On Sat 04 Mar 2023 at 10:58PM +01, Joerg Jaspert wrote:
But git or svn or even sccs and rcs is NOT, in any way, preferred
for of modification. Only one way of storage and handling some
metadata.
This is Debian's official position, but it's debateable.
There is the preferred form for modification for an individual *file*,
and that probably doesn't include version control. But the preferred
form for modifying a *project* arguably does.
I think you're *reaching* here. I know of quite a few projects where
they consider their CI setup to be an intergral part of project
development. Should we therefore declare that "preferred form of modification" could include all of the github or gitlab
infrastructure?
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 339 |
Nodes: | 16 (2 / 14) |
Uptime: | 00:04:30 |
Calls: | 7,466 |
Calls today: | 2 |
Files: | 12,691 |
Messages: | 5,627,862 |