Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
* Gary V. Vaughan wrote on Sat, May 22, 2010 at 11:21:37AM CEST: > On 22 May 2010, at 16:04, Ralf Wildenhues wrote: > > 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. > 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. Sounds like a good idea, yes. > Actually, I'd also like to see if we can use some variant of the gnulib > gen-announce script. Sounds good too, thanks. I haven't looked into gen-announce yet though. Cheers, Ralf
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
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 (g...@gnu.org)
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
[ moving from libtool@ ] Hi Gary, * 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. 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 ...) 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. Thanks, Ralf * HACKING: Set Reply-To: in announcement emails. diff --git a/HACKING b/HACKING index cbd3cfd..bea81fe 100644 --- a/HACKING +++ b/HACKING @@ -756,6 +756,7 @@ or obtained by writing to the Free Software Foundation, Inc., === To: libt...@gnu.org, autotools-annou...@gnu.org +Reply-To: bug-libt...@gnu.org Subject: GNU Libtool @VERSION@ released (alpha release). The Libtool Team is pleased to announce alpha release @VERSION@ of GNU @@ -831,6 +832,7 @@ The README file explains how to capture the verbose test output. To: info-...@gnu.org Cc: libt...@gnu.org, autotools-annou...@gnu.org +Reply-To: bug-libt...@gnu.org Subject: GNU Libtool @VERSION@ released. The Libtool Team is pleased to announce the release of GNU Libtool
