Re: [PATCH] announce-gen: Mention git commit in release announcement.

[Bruno Haible]

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