Re: Texinfo 7.0.92 pretest on AIX 7.3.1

[Gavin Smith]

On Tue, Sep 19, 2023 at 03:29:57PM +0200, Bruno Haible wrote:
> This is already fixed by gnulib commit
> https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=17c85713388407841f5c9978ecb3ccaf34ef76f1
> Interestingly, texinfo/tp/Texinfo/XS/gnulib/lib/stddef.in.h has the fix
> but texinfo/gnulib/lib/stddef.in.h does not.

Thanks, I'll update the gnulib import.

> I would have expected that you have a policy regarding which gnulib
> version to use (maybe the newest one, one week before release?
> or one of the stable branches [1]?), and am surprised to see that
> two parts of the texinfo git use different policies.

Basically, I had not thought it worth updating gnulib between pretests.
Once a pretest is out and tested, and builds successfully on some platforms,
I am loth to update gnulib again and risk breaking the build.

In the past we have done gnulib updates once before a series of pretests, and
then only update them if bugs are found in gnulib code in Texinfo (known about
based on reports of Texinfo pretests).

At the time of a release, the Gnulib checkout is set in stone.  It will not
be updated as a matter of course for any bug-fix releases; it would only
be deliberately updated if there was an apparent bug or reported compatability
issue.  This is to reassure users and distributors that we are making
minimal changes in bug-fix releases.  Many Gnulib changes may be
inconsequential or not relevant for Texinfo.  In view of this, there seems
to be little downside to fixing the Gnulib checkout at the time of the
first pretest, rather than at the eventual release.

As Patrice said in his mail, one of the gnulib imports was updated when
he imported a new module.  There may have been good reasons at the time (we
didn't discuss it) but in general I would like to be cautious about adding
new gnulib modules, especially between pretests.  It's best to discuss this
before changing anything.

I did not know about the stable branches of gnulib, and using one of these
is a possibility, but this might reduce testing of gnulib itself.  In the
past, Texinfo prereleases have occasionally found bugs in gnulib, and it
seems that using a recent development version of gnulib is a way to improve
the quality of gnulib.

Another way, I guess, is for me to check the recent gnulib ChangeLog for
any relevant changes, but this would be very hard for me to do, I expect, as
I wouldn't know which changes were important to include.

I am not saying that this is the right way of doing things, but this is
what my thought process was.  I'm open to other suggestions of ways of
doing it, ways that make it easier or better to develop either Texinfo,
or indeed Gnulib.

In short, I do not mind always updating gnulib to the latest version,
provided that platform testers repeat all their tests when we issue a
new prerelease distribution, to avoid regressions.  However, there's
no guarantee that this will happen.