2/ https://salsa.debian.org/dep-team/deps/-/merge_requests/16
This change basically adds the recommendation to use "upstreamvcs" as the name of the "git remote" to access the upstream repository and it alsoLike many others, this looks like a gratuitous change for change's sake. Countless packages have been using "upstream" for years, but apparently
+The codename can also be prefixed with the version so that branch namesSo to gain optional sorting now you lose the benefit of being able to mechanically determine the branch name? This is beyond silly.
+are correctly sorted by age of the target release in the list of available +branches. Examples: `debian/12-bookworm`, `debian/11-bullseye`, +`ubuntu/24.04-noble`, `ubuntu/22.04-jammy`.
+unlikely to clash with the packaging branches. Despite this, it is good +practice to not push any upstream branch to the packaging repository so as +to not confuse anyone about the purpose of the Git repository.WTF? I say instead that in the modern worlds it is a best practice to
1/ https://salsa.debian.org/dep-team/deps/-/merge_requests/9
(see mr9.patch attached if you don't want to look up on the web)
We had a couple of revisions already and it seems fine to me to merge
this, if anyone has valid objections (i.e. with good rationale), now is
the time to raise them. You might want to look the closed comments
on the above merge request to see whether your concerns have been
discussed already.
This change basically adds the recommendation to use "upstreamvcs" as the name of the "git remote" to access the upstream repository and it also documents the possibility to merge the upstream commits in the "upstream/latest" branch (as proposed by gbp import-orig
--upstream-vcs-tag) when your workflow is to import the upstream tarball.
On Jan 07, Raphael Hertzog <[email protected]> wrote:
This change basically adds the recommendation to use "upstreamvcs" asLike many others, this looks like a gratuitous change for change's
the
name of the "git remote" to access the upstream repository and it also
sake.
Countless packages have been using "upstream" for years, but apparently
it is not perfect enough and somebody had to invent a new name.
the tag from upstream or the tag from your import? Nominally thatshould be the same content, excepted that there are many projects that
I still believe that this is trying to codify a lot of pratices (e.g.
the obsession with pristine-tar) which are not widely accepted.
This DEP is the result of an echo chamber and is the consensus of the
few people debating it on salsa.
+The codename can also be prefixed with the version so that branchSo to gain optional sorting now you lose the benefit of being able to mechanically determine the branch name? This is beyond silly.
names
+are correctly sorted by age of the target release in the list of
available
+branches. Examples: `debian/12-bookworm`, `debian/11-bullseye`,
+`ubuntu/24.04-noble`, `ubuntu/22.04-jammy`.
WTF? I say instead that in the modern worlds it is a best practice to
have the packaging repository as a branch of the upstream repository.
Again, trying to promote personal preferences to a standard.
This change basically adds the recommendation to use "upstreamvcs"Like many others, this looks like a gratuitous change for change's sake. Countless packages have been using "upstream" for years, but apparently
as the
name of the "git remote" to access the upstream repository and it also
it is not perfect enough and somebody had to invent a new name.
Let's say upstream name their release tags like "1.2.3". That's valid and that happens.
In your Debian packaging repository, after importing that release you now have a tag named "upstream/1.2.3" if you follow the proposed convention or use some existing tooling with its default configuration.
Let's now assume that your upstream remote is named "upstream", as is common practice (I do that too).
git checkout upstream/1.2.3
the tag from upstream or the tag from your import? Nominally that shouldbe the same content, excepted that there are many projects that repack sources, and the tooling will always generate a different commit anyway. The different name is to resolve this ambiguity.
* Raphael Hertzog <[email protected]> [250107 08:39]:
1/ https://salsa.debian.org/dep-team/deps/-/merge_requests/9
(see mr9.patch attached if you don't want to look up on the web)
We had a couple of revisions already and it seems fine to me to merge
this, if anyone has valid objections (i.e. with good rationale), now is
the time to raise them. You might want to look the closed comments
on the above merge request to see whether your concerns have been
discussed already.
This change basically adds the recommendation to use "upstreamvcs" as the name of the "git remote" to access the upstream repository and it also documents the possibility to merge the upstream commits in the "upstream/latest" branch (as proposed by gbp import-orig --upstream-vcs-tag) when your workflow is to import the upstream tarball.
The name for the remote could easily have been "upstream" like
various packages are already set up and documented today. But
apparently gbp picked the IMO unwieldly name in the meantime?
Meh. But what's done is done, I guess. We'll see who will adopt that
name.
Tags in git are not prefixed with the remote name or anything else. A
tag
named upstream/1.2.3 is never from the upstream. A tag named 1.2.3
should
always be from the upstream.
Branches, on the other hand, indeed clash between "upstream/foo branch
from the maintainer" and "foo branch from the upstream".
You are free to join or discuss it here. That DEP has been online for some years now, it's not exactly happening in the hiding.Nobody mentioned hiding anything, but it's still just a few people
I mean having the packaging branch in the Debian repository, not in the upstream repository.WTF? I say instead that in the modern worlds it is a best practice toCould you please give us a few examples of projects where that already works out-of-the-box, ie the package is built and uploaded to the archive exactly as provided by upstream, debian/changelog and all?
have the packaging repository as a branch of the upstream repository.
With the obvious goal of becoming a standard.Again, trying to promote personal preferences to a standard.That's just a set of recommendations, not policy. You are free not to follow
This change basically adds the recommendation to use "upstreamvcs" as the name of the "git remote" to access the upstream repository and it also documents the possibility to merge the upstream commits in the "upstream/latest" branch (as proposed by gbp import-orig --upstream-vcs-tag) when your workflow is to import the upstream tarball.
The name for the remote could easily have been "upstream" like
various packages are already set up and documented today. But
apparently gbp picked the IMO unwieldly name in the meantime?
Meh. But what's done is done, I guess. We'll see who will adopt that
name.
Maybe before moving it to ACCEPTED, it would be useful to design a
dashboard of some kind to track adoption, not just in tooling, but in
actual packages?
This could probably be built as an extension to vcswatch.
This change basically adds the recommendation to use "upstreamvcs" as the >>>> name of the "git remote" to access the upstream repository and it also >>>> documents the possibility to merge the upstream commits in theThe name for the remote could easily have been "upstream" like
"upstream/latest" branch (as proposed by gbp import-orig
--upstream-vcs-tag) when your workflow is to import the upstream tarball. >>>
various packages are already set up and documented today. But
apparently gbp picked the IMO unwieldly name in the meantime?
Meh. But what's done is done, I guess. We'll see who will adopt that
name.
This is what git-buildpackage already has. Nothing stops people from suggesting other names. I remember Guido mentioning at one point he is
open to change it or to make it configurable.
Personally I feel that just picking a reasonably good name and
sticking to it for now is the best return on investment for Debian.
The 'upstreamvcs' is reasonably good and unambiguous on what it means,
and it won't get mixed up with `upstream/*` tag names.
On Jan 07, Raphael Hertzog <[email protected]> wrote:
This change basically adds the recommendation to use "upstreamvcs" as the name of the "git remote" to access the upstream repository and it alsoLike many others, this looks like a gratuitous change for change's sake. Countless packages have been using "upstream" for years, but apparently
it is not perfect enough and somebody had to invent a new name.
Like many others, this looks like a gratuitous change for change's sake. Countless packages have been using "upstream" for years, but apparently
it is not perfect enough and somebody had to invent a new name.
I still believe that this is trying to codify a lot of pratices (e.g.
the obsession with pristine-tar) which are not widely accepted.
This DEP is the result of an echo chamber and is the consensus of the
few people debating it on salsa.
+The codename can also be prefixed with the version so that branch names +are correctly sorted by age of the target release in the list of available +branches. Examples: `debian/12-bookworm`, `debian/11-bullseye`, +`ubuntu/24.04-noble`, `ubuntu/22.04-jammy`.So to gain optional sorting now you lose the benefit of being able to mechanically determine the branch name? This is beyond silly.
+unlikely to clash with the packaging branches. Despite this, it is good +practice to not push any upstream branch to the packaging repository so as +to not confuse anyone about the purpose of the Git repository.WTF? I say instead that in the modern worlds it is a best practice to
have the packaging repository as a branch of the upstream repository.
Again, trying to promote personal preferences to a standard.
Given that the "upstream" branch name cames from the git-buildpackage and that it's git-buildpackage which introduced "upstreamvcs", it seems fair
to me to standardize on this name.
The MR above has additional links and descriptions of current
practices. I do not have a strong preference for a choice yet so
feedback would be appreciated.
Maybe before moving it to ACCEPTED, it would be useful to design a
dashboard of some kind to track adoption, not just in tooling, but in
actual packages?
On Sat, 11 Jan 2025 12:00:27 +0100, Raphael Hertzog wrote:
Given that the "upstream" branch name cames from the git-buildpackage and that it's git-buildpackage which introduced "upstreamvcs", it seems fair
to me to standardize on this name.
In theory, yes. In pratice, quoting myself:
| As a data point, the Debian Perl Group is using "upstream-repo" for
| this additional remote in its tools since December 2013.
Not that one is better than the other, and although I like to follow git-buildpackage in general, having to change the names on 4000+
remotes on dozens of developers' machine is annoying.
[ Adding Guido in copy, replying to an old mail ]
Hello Gregor,
On Sun, 12 Jan 2025, gregor herrmann wrote:
On Sat, 11 Jan 2025 12:00:27 +0100, Raphael Hertzog wrote:
Given that the "upstream" branch name cames from the git-buildpackage and that it's git-buildpackage which introduced "upstreamvcs", it seems fair to me to standardize on this name.
In theory, yes. In pratice, quoting myself:
| As a data point, the Debian Perl Group is using "upstream-repo" for
| this additional remote in its tools since December 2013.
Not that one is better than the other, and although I like to follow git-buildpackage in general, having to change the names on 4000+
remotes on dozens of developers' machine is annoying.
I can certainly sympathize with that. I don't have any strong personal preference in the name but since the goal is to standardize across tools,
we need to pick one.
Can you point out which tools in the Perl group use that remote name?
How easy is it to tweak those tools to perform the rename of the remote
in some dynamic fashion?
I mean "git remote rename upstream-repo upstreamvcs" could be called automatically by a newer version of your tools. Or a more complex set
of commands that would duplicate the remote instead of renaming it.
On the other side, we could check whether Guido would be willing to update git-buildpackage to use "upstream-repo" as default? I don't know since
when "uptsreamvcs" is a thing and whether changing the default again would have serious drawbacks.
But if I have to pick one or the other name, I'm more inclined to follow
the lead of git-buildpackage since it's more widely used than the above helper tools of the Perl team.
Have a nice day!
--
⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <[email protected]>
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
On Thu, Mar 20, 2025 at 06:10:35PM +0100, Raphael Hertzog wrote:
Hello Gregor,
On Sun, 12 Jan 2025, gregor herrmann wrote:
On Sat, 11 Jan 2025 12:00:27 +0100, Raphael Hertzog wrote:I can certainly sympathize with that. I don't have any strong personal
Given that the "upstream" branch name cames from the git-buildpackage andIn theory, yes. In pratice, quoting myself:
that it's git-buildpackage which introduced "upstreamvcs", it seems fair >> > > to me to standardize on this name.
| As a data point, the Debian Perl Group is using "upstream-repo" for
| this additional remote in its tools since December 2013.
Not that one is better than the other, and although I like to follow
git-buildpackage in general, having to change the names on 4000+
remotes on dozens of developers' machine is annoying.
preference in the name but since the goal is to standardize across tools,
we need to pick one.
Can you point out which tools in the Perl group use that remote name?
How easy is it to tweak those tools to perform the rename of the remote
in some dynamic fashion?
On the other side, we could check whether Guido would be willing to update >> git-buildpackage to use "upstream-repo" as default? I don't know sinceThe work within gbp is almost zero. I'm aware of some scripts that rely
when "uptsreamvcs" is a thing and whether changing the default again would >> have serious drawbacks.
on the naming though and we don't know what else exists outside of gbp
(and there's also users outside Debian) so if we don't *have* to change
the name that would be better.
I (finally) hada quick look, and it should be fairly easy to add the
rename to dpt-upstream-repo, which is also called by our .mrconfig
setup. Looks like a quick DebCamp project.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 163:25:33 |
| Calls: | 12,095 |
| Calls today: | 3 |
| Files: | 15,000 |
| Messages: | 6,517,786 |