[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: announce-gen

From: Jim Meyering
Subject: Re: announce-gen
Date: Fri, 29 Apr 2011 22:48:09 +0200

Reuben Thomas wrote:
> On 29 April 2011 21:21, Jim Meyering <address@hidden> wrote:
>> Reuben Thomas wrote:
>>> I'm trying to prepare a small cosmetic patch to fix up a couple of
>>> things I find myself manually fixing up:
>>> 1. "./NEWS". I considered replacing this with the basename of the NEWS
>>> file, but in fact it seems to me it's better to use the literal "NEWS"
>>> since that makes more sense in the email. What do you think?
>> Neither would work.
>> Using the basename wouldn't work in general, since it might be
>> invoked with --news=$(srcdir)/NEWS --news=$(srcdir)/sub-project/NEWS
>> If you simply remove any "./" prefix, that would be great.
> OK.

Please make that a separate change.

>>> 2. In the email subject, better use $package_name $curr_version than
>>> $my_distdir.
>> All of my announcement Subjects have used $my_distdir (i.e., package-X.Y)
>> for years.  You can see that policy reflected in README-release's
>> suggested "Subject: coreutils-X.Y released [stable]", too.
>> Yet you prefer to use a space in place of the "-"?
> Yes, because the subject of an email should be human language, not
> computerese. I am releasing, for example, "zile 2.3.24", not
> "zile-2.3.24". Really, even that is not ideal. In autoconf terms, I
> would rather have PACKAGE_NAME VERSION (in this case, "Zile 2.3.24").
> But removing the space gets almost all of the effect intended for much
> less effort (as PACKAGE_NAME isn't available in announce-gen, and
> confusingly PACKAGE is called $package_name).
>> This seems pretty deeply seated to me, and I'd rather not change it.
> Announcing things with human-readable typography rather than
> computer-readable typography seems deep-seated just about everywhere
> else I look.

If no one else feels strongly enough about this to
speak up, I'm willing to drop the "-", but let's defer
that change until README-release is in gnulib, so that
you can make the same cosmetic change in that file, too.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]