Hi Simon,
> including the commit hash provide some additional information that may
> be useful further down the line
That is a bit weak as a rationale. There are many additional informations
that "may be useful" to include. Isn't this move part of a bigger plan of
yours, which is to decompose release tarballs [1][2][3]?
The problem I see with your patch is that it goes into a wrong direction.
In [1], I stated my objection: The release announcement is the wrong place
to add such information. You replied "It is better than nothing, though."
No, it's not better than nothing. It increases the future costs of moving
the ship into the right direction. The longer one has been sailing in the
wrong direction, the more costly it becomes to sail to the real goal.
More precisely, the release announcement is
1) written for humans, not meant to be machine-readable,
2) published on a different channel than tarballs.
Your real goal, which is — AFAIU — to allow distros to discard part
or all of the tarball and to redo the packaging work done by the release
manager in a different way, would be better served with a
1) machine-readable file,
2) somewhere in or in the vicinity of the tarball.
That is, it would be better if you design a new file format (*), containing
vcs:
type: git
url: https://git.savannah.gnu.org/git/libidn.git
commit: d0eb2b5a596f8bca26b0b2ccf0c70311b9819e6f
label: v1.42
build-tools:
- gnulib
type: git
url: https://git.savannah.gnu.org/git/gnulib.git
commit: aacceb6eff58eba91290d930ea9b8275699057cf
- autoconf
type: release
distributor: gnu.org
version: 2.71
- automake
type: release
distributor: gnu.org
version: 1.16.5
- bison
type: release
distributor: gnu.org
version: 3.8.2
- m4
type: release
distributor: gnu.org
version: 1.4.18
- makeinfo
type: release
distributor: gnu.org
version: 6.8
- help2man
type: release
distributor: gnu.org
version: 1.49.1
- make
type: release
distributor: gnu.org
version: 4.3
- gzip
type: release
distributor: gnu.org
version: 1.10
- tar
type: release
distributor: gnu.org
version: 1.34
Then call that file format the "metainfo" of the release, and either
- include a .tarball-metainfo in the tarball itself. (Some packages
already have a .tarball-version.)
or
- formulate a convention that this file be available on the same ftp
server, under the name PACKAGE.metainfo, next to PACKAGE.tar.gz.
(*) My example uses YAML syntax, but JSON or XML would be just as good.
> and turn that into this:
>
> This release was built bootstrapped with the following tools
> using inetutils git commit 524d4b6934db12b9f43be410d2f201fdb40cfc97:
>
> Gnulib aacceb6eff
> Autoconf 2.71
> Automake 1.16.5
> Bison 3.8.2
> M4 1.4.18
> Makeinfo 6.8
> Help2man 1.49.1
> Make 4.3
> Gzip 1.10
> Tar 1.34
>
> Does this make sense?
As a naïve user, I would have two thoughts:
* Why is he telling me a git commit this way? Has he not heard of
"git tag" and "git push --tags"?
* Why do you make my brain jump from the tools to the commit id and then
back again to the tools?
In other words, if you really want to go this way — against the advice that
I gave you above —, better replace the two lines with:
This release is based on the inetutils git, available at
https://git.savannah.gnu.org/git/inetutils.git
commit 524d4b6934db12b9f43be410d2f201fdb40cfc97, also labelled v1.42.
The release tarball was built using the following tools:
Bruno
[1] https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00242.html
[2] https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00431.html
[3] https://lists.gnu.org/archive/html/bug-gnulib/2024-05/msg00124.html
