Re: [PATCH] README-release improvements

[Gary V. Vaughan]

On 21 Oct 2011, at 16:11, Bruno Haible wrote:
> Hi Gary,

Hi Bruno,

Thanks for the feedback.

>> Set a neutral locale for rolling the release tarballs.
> 
> I disagree with this advice. Yes, the first time you run a "make distcheck"
> in a German locale, 'makeinfo' may put German strings into your formatted
> documentation. But "make distcheck" ought to work for any user as well
> as for yourself. And many users will run "make check" in German, Japanese,
> or Chinese locales. Therefore you should better fix the Makefile problems
> that you have in this area, not push them under the rug.

Git blame puts the introduction of the LC_ALL line to our release checklist
here (which doesn't shed any light on it unfortunately):

commit 2db08b36f61c63db299b1387fa974668d05465d3
Author: Ralf Wildenhues <address@hidden>
Date:   Tue Apr 26 11:55:12 2005 +0000

    * HACKING, THANKS: Updated.

I assume Ralf did this so that we can be certain of not accidentally uploading
a release with German localisation strings in it, and/or because some of our
test-cases break in another locale.  I haven't looked any deeper than that tho'
so I'm quite happy to leave it in gl/top/README-release.diff until I've had the
time to investigate properly.

>> Use ./build-aux/ when calling a script, since some shells won't
>> run a script relative to the current directory unless "." is in
>> the command search PATH.
> 
> The "./" is needed in front of file names that don't contain a slash.
> For file names that do contain a slash, no search in $PATH is performed;
> it is always relative to the current directory. See POSIX:2008
> <http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html>
> section 2.9.1, subsection "Command Search and Execution".
> 
> If you know about "some shells" that do that wrong, please first have the
> Autoconf manual, chapter "Portable Shell Programming", updated.

I had misremembered my old bash-2.05 doing it that way, but I've long since
moved to a zsh login shell which doesn't have that problem.  I'll remove
that and repost after addressing Jim's review too.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)