Re: [PATCH] maintainer-makefile: Improve gnulib-version derivation.

[Simon Josefsson]

Bruno Haible via Gnulib discussion list <bug-gnulib@gnu.org> writes:

> Simon Josefsson wrote:
>> This also change from using 'git describe || git rev-parse --short=10'
>> to using 'git rev-parse', which results in announcement to look like
>> this:
>> 
>>      This release was bootstrapped with the following tools:
>>        Gnulib 552c0b06355a6720c8ce87ce305f42ed15a32d20
>> 
>> instead of
>> 
>>      This release was bootstrapped with the following tools:
>>        Gnulib v1.0-1286-g552c0b0635
>> 
>> and while I would agree that the full SHA1 isn't the prettiest ...
>
> In an earlier discussion, I mentioned that for the purpose of the
> reproducible tarballs, the meta-information about the used Gnulib
> and Autotools versions should be in a machine-readable file, *not*
> in a release announcement (since the latter is distributed in mailing
> lists).
>
> But if you put information into release announcements, it would be
> good to make an effort to make it meaningful for a human reader.
>
> A line
>          Gnulib v1.0-1286-g552c0b0635
> was meant to be useful for a human, but never was, since Gnulib
> has no release tags other than v0.1 and v1.0.
>
> A line
>          Gnulib 552c0b06355a6720c8ce87ce305f42ed15a32d20
> is completely useless for a human.
>
> What a human reader would like to understand is whether such a
> commit number is recent or not. Therefore, what I would suggest
> is to suffix it with a date:
>
>          Gnulib 552c0b06355a6720c8ce87ce305f42ed15a32d20 (2024-12-28)

I agree. Even the date is more human friendly, so how about

  Gnulib 2024-12-28 (552c0b06355a6720c8ce87ce305f42ed15a32d20)

?

The TZ question arise here again (git commit timestamp vs TZ-less
ChangeLog date), but let's hope it won't be a big problem in practice.

/Simon

signature.asc
Description: PGP signature