I'm revisiting this before an upcoming release.  Jim and Paul was in
favor of this, but I'm trying to address some of Bruno's concerns below.

Bruno Haible <br...@clisp.org> writes:

> 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.

Do you have some example?

Having the git tag and git commit identifier is missing from our
announcements today, and I believe a lot of people do look into our git
repositories; if for no other reason to compare that our tarballs
correspond to what's in git.  The git tag and commit identifier are
important and missing.

> Isn't this move part of a bigger plan of yours, which is to decompose
> release tarballs [1][2][3]?

I don't think getting rid of release tarballs will be feasible or
necessarily even a good idea (think about re-bootstrapping systems --
you need proper release tarballs for that), so no; but I do think we
should start publishing minimal source-only signed tarballs (git-archive
outputs) in addition to release tarballs.

> 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.

I agree this would be nice, but I don't have energy to pursue it, and
believe it is orthogonal to what I desire here.

There are some ambitious projects like in-toto:
https://github.com/in-toto/specification/blob/v1.0/in-toto-spec.md

>> 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:

You are right the git tag is useful and should also be present!  Many
people will look for it to find the proper commit.  However git tags can
be moved later on, so the git commit identifier is still useful.

Recently I noticed this project:

https://github.com/not-an-aardvark/lucky-commit

Even publishing a short commit identifier, which I considered first, is
not sufficient here.

I thought about the order in which things are presented in the
announcement, and one thing that stood out to me is that we talk about
'git shortlog' early: even before the URLs to tarballs.  I think it
makes more sense to move this to after speaking about the git clone URL
and the git commit/tag.  The bootstrapping tool version info should go
somewhere, and it is currently last before NEWS and I can't find any
better place for it.

I have pushed the attached patch the results in announcements like the
one below (assuming --cksum-checksums is used):

To: gnutls-h...@lists.gnutls.org
Cc: coordina...@translationproject.org
Subject: guile-gnutls-4.0.2 released [alpha]

<#secure method=pgpmime mode=sign>
This is to announce guile-gnutls-4.0.2, a alpha release.

FIXME: put comments here

There have been 6 commits by 2 people in the 29 days since 4.0.1.

See the NEWS below for a brief summary.

Thanks to everyone who has contributed!
The following people contributed changes to this release:

  Simon Josefsson (5)
  Vivien Kraus (1)

Simon
 [on behalf of the guile-gnutls maintainers]
==================================================================

Here is the GNU guile-gnutls home page:
    https://gnu.org/s/guile-gnutls/

Here are the compressed sources and a GPG detached signature:
  https://alpha.gnu.org/gnu/guile-gnutls/guile-gnutls-4.0.2.tar.gz
  https://alpha.gnu.org/gnu/guile-gnutls/guile-gnutls-4.0.2.tar.gz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.org/order/ftp.html

Here are the SHA1 and SHA256 checksums:

  9c298939a44fd68ec3fb645941d767765c8b4a13  guile-gnutls-4.0.2.tar.gz
  ZdVcy5xlyVifqsKQ9mFKYV5r/Hj8lCFtP/XSdPWWkPQ=  guile-gnutls-4.0.2.tar.gz

Verify the base64 SHA256 checksum with cksum -a sha256 --check
from coreutils-9.2 or OpenBSD's cksum since 2007.

Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify guile-gnutls-4.0.2.tar.gz.sig

The signature should match the fingerprint of the following key:

  pub   ed25519 2019-03-20 [SC]
        B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE
  uid   Simon Josefsson <si...@josefsson.org>

If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.

  gpg --locate-external-key si...@josefsson.org

  gpg --recv-keys 51722B08FE4745A2

  wget -q -O- 
'https://savannah.gnu.org/project/release-gpgkeys.php?group=guile-gnutls&download=1'
 | gpg --import -

As a last resort to find the key, you can try the official GNU
keyring:

  wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
  gpg --keyring gnu-keyring.gpg --verify guile-gnutls-4.0.2.tar.gz.sig

This release is based on the guile-gnutls git repository, available as

  git clone https://git.savannah.gnu.org/git/guile-gnutls.git

with commit 2d420c4fc1304e816d7e20ded829812f3f840212 tagged as v4.0.2.

For a summary of changes and contributors, see:

  https://git.sv.gnu.org/gitweb/?p=guile-gnutls.git;a=shortlog;h=v4.0.2

or run this command from a git-cloned guile-gnutls directory:

  git shortlog v4.0.1..v4.0.2

This release was bootstrapped with the following tools:
  Autoconf 2.71
  Automake 1.16.5
  Makeinfo 6.8
  Libtoolize 2.4.6

NEWS

* Noteworthy changes in release 4.0.2 (2024-12-10) [alpha]

** EdDSA curve manipulation should use #f for the y parameter of the public-key.

/Simon
From 45db9fb46adaf2f88529a52f3c94ac4fdc82e33e Mon Sep 17 00:00:00 2001
From: Simon Josefsson <si...@josefsson.org>
Date: Tue, 10 Dec 2024 09:57:33 +0100
Subject: [PATCH 2/2] announce-gen: Mention git commit and tag in announcement.

* build-aux/announce-gen (this_commit_hash): New variable.
(main): Print git commit hash and tag.
(main): Put git-log info near git and NEWS info.
---
 ChangeLog              |  7 +++++++
 build-aux/announce-gen | 26 ++++++++++++++++++++------
 2 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 09ac44d1c7..5bfb71b28d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2024-05-12  Simon Josefsson  <si...@josefsson.org>
+
+	announce-gen: Mention git commit and tag in announcement.
+	* build-aux/announce-gen (this_commit_hash): New variable.
+	(main): Print git commit hash and tag.
+	(main): Put git-log info near git and NEWS info.
+
 2024-12-10  Simon Josefsson  <si...@josefsson.org>
 
 	maintainer-makefile: Pass on $(announce_gen_args) to announce-gen.
diff --git a/build-aux/announce-gen b/build-aux/announce-gen
index 318eeb19e4..cc1d46039f 100755
--- a/build-aux/announce-gen
+++ b/build-aux/announce-gen
@@ -35,7 +35,7 @@
 eval 'exec perl -wSx "$0" "$@"'
      if 0;
 
-my $VERSION = '2024-12-02 20:10'; # UTC
+my $VERSION = '2024-12-10 08:57'; # UTC
 # The definition above must lie within the first 8 lines in order
 # for the Emacs time-stamp write hook (at end) to update it.
 # If you change this file with Emacs, please let the write hook
@@ -572,6 +572,8 @@ EOF
   chomp (my $n_ci = `git rev-list "v$v0..v$v1" | wc -l`);
   chomp (my $n_p = `git shortlog "v$v0..v$v1" | grep -c '^[^ ]'`);
 
+  my $this_commit_hash = `git log --pretty=%H -1 "v$v1"`;
+  chop $this_commit_hash;
   my $prev_release_date = `git log --pretty=%ct -1 "v$v0"`;
   my $this_release_date = `git log --pretty=%ct -1 "v$v1"`;
   my $n_seconds = $this_release_date - $prev_release_date;
@@ -593,11 +595,6 @@ $first_name [on behalf of the $package_name maintainers]
 Here is the GNU $package_name home page:
     https://gnu.org/s/$package_name/
 
-For a summary of changes and contributors, see:
-  https://git.sv.gnu.org/gitweb/?p=$package_name.git;a=shortlog;h=v$v1
-or run this command from a git-cloned $package_name directory:
-  git shortlog v$v0..v$v1
-
 EOF
 
   if (@url_dir_list == 1 && @tarballs == 1)
@@ -691,6 +688,23 @@ keyring:
   gpg --keyring gnu-keyring.gpg --verify $tarballs[0].sig
 EOF
 
+  print <<EOF;
+
+This release is based on the $package_name git repository, available as
+
+  git clone https://git.savannah.gnu.org/git/$package_name.git
+
+with commit $this_commit_hash tagged as v$v1.
+
+For a summary of changes and contributors, see:
+
+  https://git.sv.gnu.org/gitweb/?p=$package_name.git;a=shortlog;h=v$v1
+
+or run this command from a git-cloned $package_name directory:
+
+  git shortlog v$v0..v$v1
+EOF
+
   my @tool_versions = get_tool_versions (\@tool_list, $gnulib_version);
   @tool_versions
     and print "\nThis release was bootstrapped with the following tools:",
-- 
2.46.0

Attachment: signature.asc
Description: PGP signature

Reply via email to