Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).

[Gary V. Vaughan]

On 22 May 2010, at 16:04, Ralf Wildenhues wrote:
> Hi Gary,

Hallo Ralf,

> * Gary V. Vaughan wrote on Fri, May 21, 2010 at 02:22:09AM CEST:
>> The Libtool Team is pleased to announce release candidate 2.2.7b of GNU
>> Libtool.  If there are no serious deficiencies reported in this release,
>> it will be renumbered as 2.2.8 and re-released (otherwise, we'll fix
>> any problems and put out 2.2.7d first).
> 
> Thank you for cutting the alpha release, and fixing the issues you found
> along the way.

No problem.  I only volunteered because I'd forgotten that our current
release process requires several hours of CPU time and a couple of days
of monitoring and restarting testsuite runs in different modes :-p

Actually, I'm hoping that if I get in the habit of rolling releases every
2 or 3 months I won't forget the process every time, and that the tree
won't change so much and be so far from the next scheduled release that
I have to be so extremely meticulous... so the whole thing should get a
lot easier.

> As a veeery minor nit may I note that with git, it is common to separate
> the first line of the commit entry from the rest, in order for 'git log
> --oneline' to work as expected.  I'm not sure whether they relaxed that,
> because I would have expected the shortlog mail for v2.2.7b to contain
> long log lines because of that missing empty line.  Anyway, much talk,
> little problem.  (Yes, the ChangeLog style is rather the other way, with
> no empty lines within one commit entry; I use a short editor macro to
> convert between them ...)

Git is huge and complex, and I don't get to use it as often as I'd like,
so I rely on our clcommit.m4sh script to do the heavy lifting.  Are you
saying that I should patch clcommit.m4sh to insert an empty line in the
extracted ChangeLog message after the first line of text (provided that
first line doesn't begin with an asterisk)?  If so, I'll do that presently
to avoid a repeat in the next release.

> When writing a release announcement, I usually forget to set reply-to or
> mail-f'up-to.  I know that it is a contentious topic whether to use one
> or the other, and there are lots of reasons both ways (reply-to
> shouldn't go to list here to facilitate security responses to author
> only, mail-f'up-to isn't honored by many MUA's etc.), but still, would
> you guys be ok with the following patch?  Having replies go to announce
> lists seems wrong and unnecessary.

Agreed.

Actually, I'd also like to see if we can use some variant of the gnulib
gen-announce script.  Although, after 2 complete reads of the Camel 
book, Perl still makes my eyes bleed (and my brain haemorrhage (sp?))...
so I'll probably have to rewrite it in a maintainable language if it
doesn't work as-is :(

Cheers,
-- 
Gary V. Vaughan (address@hidden)