Reuben Thomas wrote: > On 29 April 2011 21:21, Jim Meyering <j...@meyering.net> 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.
