Re: README-release

Hi Simon, > I think we need one manually invoked rule like 'release-commit' to > create a version tag and set the release type, since this information > cannot come from any other place but the maintainer. The file > .tarball-version is generated, isn't it? Indeed, build-aux/git-version-gen's co

[PATCH] README-release: also run any check-very-expensive tests

FYI, I've just pushed this: >From 29596f8db284a461933f2cff775bc65399f2efbc Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Tue, 19 Jun 2018 15:47:53 -0700 Subject: [PATCH] README-release: also run any check-very-expensive tests * top/README-release: Adjust instructions so they run t

Re: Not distributing README-release automatically.

On Tue, Mar 14, 2017 at 11:28 AM, Mathieu Lirzin wrote: ... > Here is an updated patch with a rationale in the ChangeLog: > > Thanks for the review (to both of you). Thank you. I've pushed that.

Re: Not distributing README-release automatically.

18914ee59646 Mon Sep 17 00:00:00 2001 From: Mathieu Lirzin Date: Tue, 14 Mar 2017 12:19:40 +0100 Subject: [PATCH] gnulib-tool: don't automatically distribute files from top/ * gnulib-tool (func_get_automake_snippet_unconditional): To be able to not distribute top/README-release by default, d

Re: Not distributing README-release automatically.

On Tue, Mar 14, 2017 at 10:34 AM, Bruno Haible wrote: > Mathieu Lirzin wrote: >> Here is the patch: > > Given the code from gnulib-tool that you are removing, I think: > >> +EXTRA_DIST += top/GNUmakefile > > This should read > >EXTRA_DIST += $(top_srcdir)/GNUmakefile > >> +EXTRA_DIST += top/ma

Re: Not distributing README-release automatically.

Mathieu Lirzin wrote: > Here is the patch: Given the code from gnulib-tool that you are removing, I think: > +EXTRA_DIST += top/GNUmakefile This should read EXTRA_DIST += $(top_srcdir)/GNUmakefile > +EXTRA_DIST += top/maint.mk This should read EXTRA_DIST += $(top_srcdir)/maint.mk othe

Re: Not distributing README-release automatically.

On Tue, Mar 14, 2017 at 4:34 AM, Mathieu Lirzin wrote: > Jim Meyering writes: > >> On Tue, Mar 7, 2017 at 8:08 AM, Mathieu Lirzin wrote: >>> >>> Jim Meyering writes: >>> >>>> On Sun, Mar 5, 2017 at 8:12 AM, Mathieu Lirzin wrote: >>&g

Re: Not distributing README-release automatically.

Jim Meyering writes: > On Tue, Mar 7, 2017 at 8:08 AM, Mathieu Lirzin wrote: >> >> Jim Meyering writes: >> >>> On Sun, Mar 5, 2017 at 8:12 AM, Mathieu Lirzin wrote: >>>> >>>> I have been using 'readme-release' module and w

Re: Not distributing README-release automatically.

Jim Meyering writes: > On Tue, Mar 7, 2017 at 8:08 AM, Mathieu Lirzin wrote: >> Hello Jim, >> >> Jim Meyering writes: >> >>> On Sun, Mar 5, 2017 at 8:12 AM, Mathieu Lirzin wrote: >>>> >>>> I have been using 'readme-release&#x

Re: Not distributing README-release automatically.

On Tue, Mar 7, 2017 at 8:08 AM, Mathieu Lirzin wrote: > Hello Jim, > > Jim Meyering writes: > >> On Sun, Mar 5, 2017 at 8:12 AM, Mathieu Lirzin wrote: >>> >>> I have been using 'readme-release' module and was surprised to discover >>> that

Re: Not distributing README-release automatically.

Hello Jim, Jim Meyering writes: > On Sun, Mar 5, 2017 at 8:12 AM, Mathieu Lirzin wrote: >> >> I have been using 'readme-release' module and was surprised to discover >> that the "README-release" file was automatically distributed without any >&

Re: Not distributing README-release automatically.

On Sun, Mar 5, 2017 at 8:12 AM, Mathieu Lirzin wrote: > Hello, > > I have been using 'readme-release' module and was surprised to discover > that the "README-release" file was automatically distributed without any > mention in the "module/readme-rele

Not distributing README-release automatically.

Hello, I have been using 'readme-release' module and was surprised to discover that the "README-release" file was automatically distributed without any mention in the "module/readme-release" file. After some digging I have discovered that all files from the &qu

Re: [PATCH 2/4] README-release: shorten the circuit to post a news

Akim Demaille wrote: ... > While at it: I see that the release messages from the coreutils are > much richer (contributors etc.). Is there any desire to move this > in gnulib? I've included below the script that I've been using to generate the added prefix for each release announcement. Here's t

Re: [PATCH 2/4] README-release: shorten the circuit to post a news

Le 30 juil. 2012 à 14:26, Jim Meyering a écrit : > Akim Demaille wrote: >> * top/README-release: Point directly to the news submission form. > ... > > Looks fine. One suggestion, to save a line: > >> + If it does not work, then enable "News" for the proj

Re: [PATCH 2/4] README-release: shorten the circuit to post a news

Akim Demaille wrote: > * top/README-release: Point directly to the news submission form. ... Looks fine. One suggestion, to save a line: > diff --git a/top/README-release b/top/README-release > index 15110d4..1c0f760 100644 > --- a/top/README-release > +++ b/top/README-rele

[PATCH 2/4] README-release: shorten the circuit to post a news

* top/README-release: Point directly to the news submission form. --- ChangeLog | 5 + top/README-release | 12 ++-- 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/ChangeLog b/ChangeLog index 521b75a..f0c9243 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5

Re: README-release patch

Reuben Thomas wrote: > Ping? My other (rejected) patch has been responded to, but not this > one. Sorry to be a pain, but I'm working on a (per-project) patch to > README-release, and I'd like to get this patch accepted or rejected so > I know what I'm basing my per-

Re: README-release patch

Ping? My other (rejected) patch has been responded to, but not this one. Sorry to be a pain, but I'm working on a (per-project) patch to README-release, and I'd like to get this patch accepted or rejected so I know what I'm basing my per-project patch on! On 13 July 2012 11:54

Re: Reorder a couple of steps in README-release

On 13 July 2012 21:00, Jim Meyering wrote: > >>>From a53f102b0d7cc8dd8db6a632321ba8b623e56f58 Mon Sep 17 00:00:00 2001 >> From: Reuben Thomas >> Date: Fri, 13 Jul 2012 11:56:10 +0100 >> Subject: [PATCH 2/2] README-release: reorder some steps >> >> * to

Re: Reorder a couple of steps in README-release

On 07/13/2012 02:00 PM, Jim Meyering wrote: > Reuben Thomas wrote: >> The attached patch simply moves a paragraph so that the step of >> pushing the final (NEWS-updating) commits to git happens before >> uploading any release files. > > Hi Reuben, > > Thanks for the suggestion, but I deliberately

Re: Reorder a couple of steps in README-release

I feel I cannot reasonably revert that. >>From a53f102b0d7cc8dd8db6a632321ba8b623e56f58 Mon Sep 17 00:00:00 2001 > From: Reuben Thomas > Date: Fri, 13 Jul 2012 11:56:10 +0100 > Subject: [PATCH 2/2] README-release: reorder some steps > > * top/README-release: push NEWS changes

Reorder a couple of steps in README-release

ect: [PATCH 2/2] README-release: reorder some steps * top/README-release: push NEWS changes before uploading release --- ChangeLog |5 + top/README-release | 10 +- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/ChangeLog b/ChangeLog index 097c90d..fe11

README-release patch

Tue, 29 May 2012 09:09:28 +0100 Subject: [PATCH] README-release: make it more legible * top/README-release: improve typography slightly. --- top/README-release | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/top/README-release b/top/README-release index 321c185..

Re: Slight typographical improvements to README-release

x27;d rather avoid it if it's > merely a minor style issue such as arrows. Fair enough. Revised patch: --- a/top/README-release +++ b/top/README-release @@ -73,11 +73,16 @@ Once all the builds and tests have passed, announcement link in the email message. From here: + https

Re: [PATCH] readme-release: require the promoted modules

Le 7 juin 2012 à 17:02, Jim Meyering a écrit : >> Subject: [PATCH] readme-release: also require announce-gen and >> maintainer-makefile. >> >> * modules/readme-release (Depends-on): here. >> * modules/announce-gen, modules/do-release-commit-and-tag, >>

Re: [PATCH] readme-release: require the promoted modules

Akim Demaille wrote: > Le 7 juin 2012 à 15:05, Jim Meyering a écrit : > >> Akim Demaille wrote: >>> Le 5 juin 2012 à 12:05, Akim Demaille a écrit : >>> >>>> I have been trying to follow README-release as a guide >>>> for releasing Bison,

Re: [PATCH] readme-release: require the promoted modules

Le 7 juin 2012 à 15:05, Jim Meyering a écrit : > Akim Demaille wrote: >> Le 5 juin 2012 à 12:05, Akim Demaille a écrit : >> >>> I have been trying to follow README-release as a guide >>> for releasing Bison, unfortunately step after step I >>> disc

Re: [PATCH] readme-release: require the promoted modules

Akim Demaille wrote: > Le 5 juin 2012 à 12:05, Akim Demaille a écrit : > >> I have been trying to follow README-release as a guide >> for releasing Bison, unfortunately step after step I >> discovered that I needed modules that were not requested >> by Bison. It seem

Re: [PATCH] readme-release: require the promoted modules

Le 5 juin 2012 à 12:05, Akim Demaille a écrit : > I have been trying to follow README-release as a guide > for releasing Bison, unfortunately step after step I > discovered that I needed modules that were not requested > by Bison. It seems sane that if you want README-alpha, > yo

Re: [PATCH] readme-release: require the promoted modules

Le 6 juin 2012 à 22:44, Jim Meyering a écrit : > Akim Demaille wrote: >> Le 5 juin 2012 à 12:12, Jim Meyering a écrit : >> >>> Good idea. This has burned even me ;-) >>> Please commit. >> >> EPERM. > > You should be able to push that, now. Thanks, installed!

Re: [PATCH] readme-release: require the promoted modules

Akim Demaille wrote: > Le 5 juin 2012 à 12:12, Jim Meyering a écrit : > >> Good idea. This has burned even me ;-) >> Please commit. > > EPERM. You should be able to push that, now.

Re: [PATCH] readme-release: require the promoted modules

Le 5 juin 2012 à 12:12, Jim Meyering a écrit : > Good idea. This has burned even me ;-) > Please commit. EPERM.

Re: [PATCH] readme-release: require the promoted modules

Akim Demaille wrote: > I have been trying to follow README-release as a guide > for releasing Bison, unfortunately step after step I > discovered that I needed modules that were not requested > by Bison. It seems sane that if you want README-alpha, > you also want the tools it

[PATCH] readme-release: require the promoted modules

I have been trying to follow README-release as a guide for releasing Bison, unfortunately step after step I discovered that I needed modules that were not requested by Bison. It seems sane that if you want README-alpha, you also want the tools it promotes. 0001-readme-release-require-the

Re: Slight typographical improvements to README-release

On 05/29/2012 06:11 AM, Reuben Thomas wrote: > I find UTF-8 to be a great boon precisely for making plain > text more legible. UTF-8 is sometimes necessary and usually works, but even today it fails often enough that I'd rather avoid it if it's merely a minor style issue such as arrows. For examp

Re: Slight typographical improvements to README-release

sider rather whether you can > either omit the section on how to enable news as out of scope for > README-release? I fear that a footnote will in a few years get out of > sync with Savannah, and it's not hard to work out how to enable news. Back when I first had to do it, I found it

Re: Slight typographical improvements to README-release

front page. > (at least when the NEWS feature is enabled) Ah, sorry. I'd rather not start adding footnotes; consider rather whether you can either omit the section on how to enable news as out of scope for README-release? I fear that a footnote will in a few years get out of sync with Sa

Re: Slight typographical improvements to README-release

Reuben Thomas wrote: > The following makes README-release slightly easier to read, in > particular tweaking a Savannah instruction. > >>From b5e8e05c3c1f112f5fdb96a826b8d0cba0588459 Mon Sep 17 00:00:00 2001 > From: Reuben Thomas > Date: Tue, 29 May 2012 09:09:28 +0100 >

Slight typographical improvements to README-release

The following makes README-release slightly easier to read, in particular tweaking a Savannah instruction. >From b5e8e05c3c1f112f5fdb96a826b8d0cba0588459 Mon Sep 17 00:00:00 2001 From: Reuben Thomas Date: Tue, 29 May 2012 09:09:28 +0100 Subject: [PATCH] README-release: make it more legi

Re: Pushing tags in README-release

On 03/20/2012 01:52 PM, Reuben Thomas wrote: > Unless I'm missing something, there's nothing that does "git push > --tags" in README-release. Is that right? If so, I'll provide a patch. Pushing all tags may be too drastic (I tend to keep local tags that I

Re: Pushing tags in README-release

Reuben Thomas wrote: > Unless I'm missing something, there's nothing that does "git push > --tags" in README-release. Is that right? If so, I'll provide a patch. You don't want to push all tags. This pushes the just-created tag: * Push the NEWS-updating c

Pushing tags in README-release

Unless I'm missing something, there's nothing that does "git push --tags" in README-release. Is that right? If so, I'll provide a patch. -- http://rrt.sc3d.org

Re: README-release

Reuben Thomas wrote: > A slight simplification: > >>From 4ab7998acbf4f829fdecabd83dc75beedcdffea1 Mon Sep 17 00:00:00 2001 > From: Reuben Thomas > Date: Tue, 20 Mar 2012 13:37:21 + > Subject: [PATCH] README-release: simplify slightly > > * top/README-release: on

README-release

A slight simplification: >From 4ab7998acbf4f829fdecabd83dc75beedcdffea1 Mon Sep 17 00:00:00 2001 From: Reuben Thomas Date: Tue, 20 Mar 2012 13:37:21 + Subject: [PATCH] README-release: simplify slightly * top/README-release: only run "git checkout master" once. --- ChangeLog

Re: Make it easier to execute commands directly from README-release

Reuben Thomas wrote: > The following patch consistently applies the practice of breaking > commands out on to a separate line for ease of > copy-and-pasting/triple-clicking/whatever. > > +2012-02-18 Reuben Thomas > + > + README-release: make it easier to execute c

Make it easier to execute commands directly from README-release

ect: [PATCH] README-release: make it easier to execute commands * top/README-release: break commands out on to separate lines. --- ChangeLog |5 + top/README-release | 12 2 files changed, 13 insertions(+), 4 deletions(-) diff --git a/ChangeLog b/ChangeLog index 49c1

Re: README-release: more improvements

Reuben Thomas wrote: > Happily, Jim’s objections to some of my earlier suggestions removed a > great deal of the remaining patches I was going to suggest, so the > following is quite simple: Thanks. Pushed.

README-release: more improvements

000 Subject: [PATCH] README-release: various improvements --- ChangeLog |7 +++ top/README-release | 20 ++-- 2 files changed, 17 insertions(+), 10 deletions(-) diff --git a/ChangeLog b/ChangeLog index f0e6b31..ef784f7 100644 --- a/ChangeLog +++ b/ChangeLog @@ -

Re: Patch to README-release

e ahead and adjusted the one-line summary and pushed it anyway. >From eab243b0c190e877bcdfe4242ccce63bf3677529 Mon Sep 17 00:00:00 2001 From: Reuben Thomas Date: Thu, 9 Feb 2012 11:06:39 +0100 Subject: [PATCH] README-release: capitalize a word and split a line * top/README-release: Fix p

Re: Patch to README-release

On 02/08/2012 03:33 PM, Reuben Thomas wrote: > Ping? Are you talking about the patch in ? That looks OK to me. Jim?

Re: Patch to README-release

Ping? This is quite a simple patch, basically just a couple of punctuation fixes! -- http://rrt.sc3d.org

Patch to README-release

I'm going through Jim's review. It seems sensible now to feed the patches in one by one. Here's the first. >From 52b48c111fed5d3708344c430dd59f819deeb77f Mon Sep 17 00:00:00 2001 From: Reuben Thomas Date: Mon, 19 Dec 2011 09:40:14 +0100 Subject: [PATCH 1/4] Improvements to REA

Re: Patches to README-release

r any developer not using the equivalent of Fedora rawhide or Debian's unstable -- and sometimes even those lack the latest stable version of some build tool, though not for long. > If so, then my implementation in saner bootstrap is correct, and > keeping the paragraph > in README-

Re: Patches to README-release

otools releases) want to be able to run bootstrap? If so, then my implementation in saner bootstrap is correct, and keeping the paragraph in README-release we're discussing is correct too... but I need to revise my thinking about AC_PREREQ and friends a little, and not misuse them to name la

Re: Patches to README-release

x27;ve just pushed this: >From 0eab6e2c9ef1e852ec8a880e2e134670f3ceb5c2 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sat, 28 Jan 2012 10:49:35 +0100 Subject: [PATCH] doc: clarify README-release * top/README-release: Clarify: you should make a point to have the latest stable versions of bu

Re: Patches to README-release

Gary V. Vaughan wrote: > Hi Jim, > > On 28 Jan 2012, at 15:27, Jim Meyering wrote: >> Gary V. Vaughan wrote: >>> Hi Jim, >>> >>> On 28 ม.ค. 2012, at 1:21, Jim Meyering wrote: >>> >>>Reuben Thomas wrote: >>> >>>Ping? The patches still apply cleanly to HEAD. >>> >>>On 22 Decembe

Re: Patches to README-release

Hi Jim, On 28 Jan 2012, at 15:27, Jim Meyering wrote: > Gary V. Vaughan wrote: >> Hi Jim, >> >> On 28 ม.ค. 2012, at 1:21, Jim Meyering wrote: >> >>Reuben Thomas wrote: >> >>Ping? The patches still apply cleanly to HEAD. >> >>On 22 December 2011 19:54, Reuben Thomas wrote:

Re: Patches to README-release

to use at least the latest stable build tools. AC_PREREQ does not necessarily encode that requirement. > > > More succinctly: Does gnulib bootstrap deliberately not consider the > AC_PREREQ and friends versions as full and correct autotool version > bootstrap prerequisites for good reason

Re: Patches to README-release

he autotools versions in your PATH every time you want to make a new distribution tarball. More succinctly: Does gnulib bootstrap deliberately not consider the AC_PREREQ and friends versions as full and correct autotool version bootstrap prerequisites for good reason? Or is that a bug forcing th

Re: Patches to README-release

steps. ... >> >> From 1949b5fc095e746bac4ab90c30b373b79aa6507d Mon Sep 17 00:00:00 2001 >> From: Reuben Thomas >> Date: Mon, 19 Dec 2011 09:46:16 +0100 >> Subject: [PATCH 2/4] * top/README-release: fix punctuation and spacing. >>  Remove A one-line summary should not start with "*" >>

Re: Patches to README-release

2001 > From: Reuben Thomas > Date: Mon, 19 Dec 2011 09:40:14 +0100 > Subject: [PATCH 1/4] Improvements to README-release > > * top/README-release: fix punctuation and spacing. > --- >  ChangeLog          |    5 + >  top/README-release |    6 -- >  2 file

Patches to README-release

A series of patches that attempt to improve a few minor formatting problems and also streamline some of the steps. >From a7fef6319b09420f26fc6d2a508322b7c21b7997 Mon Sep 17 00:00:00 2001 From: Reuben Thomas Date: Mon, 19 Dec 2011 09:40:14 +0100 Subject: [PATCH 1/4] Improvements to README-rele

Re: [PATCH] README-release improvements

my discretion. Like Jim, I'm leary of > recommending git clean in the README-release incase someone follows it and > deletes an important untracked file by mistake. > I'm with you in this (and that's why I didn't suggest the use of "git clean"). > I think after thi

Re: [PATCH] README-release improvements

es >> ./configure # regenerate Makefile explicitly -"- -"- >> > At this point, wouldn't it be simpler (and maybe safer) to clone the git > repository in a new directory, and simply do "./bootstrap && ./configure" > from there?

Re: [PATCH] README-release improvements

On Saturday 22 October 2011, Jim Meyering wrote: > Stefano Lattarini wrote: > >> make -k maintainer-clean # Clean up previous build artefacts > >> ./configure > >> make maintainer-clean# Clean up previous build artefacts > >> git checkout master > >> git pull origin master # don't t

Re: [PATCH] README-release improvements

Stefano Lattarini wrote: > Hi everybody. Just my two cents about this matter ... > > On Saturday 22 October 2011, Bruno Haible wrote: >> Gary V. Vaughan wrote: >> > >> Running the (potentially) outdated configure, to build a (potentially) >> > >> outdated Makefile, which may very well rerun acloc

Re: [PATCH] README-release improvements

Hi everybody. Just my two cents about this matter ... On Saturday 22 October 2011, Bruno Haible wrote: > Gary V. Vaughan wrote: > > >> Running the (potentially) outdated configure, to build a (potentially) > > >> outdated Makefile, which may very well rerun aclocal, automake, autoconf > > >> etc

Re: [PATCH] README-release improvements

Gary V. Vaughan wrote: ... > Okay to push? Yes, but with the following changes applied: use this instead, per today's discussion: make -k maintainer-clean || { ./configure && make maintainer-clean; } and change "incase" to "in case" in the commit

Re: [PATCH] README-release improvements

Hi Jim, > > ./configure > > make maintainer-clean# Clean up previous build artefacts > > What's the point of rerunning configure and maintainer-clean? I sometimes do "make distclean" in a subdirectory. This removes some but not all Makefiles. "make -k maintainer-clean" will thus fail and

Re: [PATCH] README-release improvements

Bruno Haible wrote: > Gary V. Vaughan wrote: >> >> Running the (potentially) outdated configure, to build a (potentially) >> >> outdated Makefile, which may very well rerun aclocal, automake, autoconf >> >> etc just to call the maintainer-clean rule, and then blow it all away >> >> in the next step

Re: [PATCH] README-release improvements

an" is a requirement. > A patch with that improvement would be welcome. Okay to push? -- readme-release: several release instructions improvements. * README-release: Don't git pull all branches when only master is needed for the release process. Don't try to run ./confi

Re: [PATCH] README-release improvements

Hi Jim, Gary V. Vaughan wrote: > >> Running the (potentially) outdated configure, to build a (potentially) > >> outdated Makefile, which may very well rerun aclocal, automake, autoconf > >> etc just to call the maintainer-clean rule, and then blow it all away > >> in the next step with a bootstrap

Re: [PATCH] README-release improvements

Gary V. Vaughan wrote: > Hi Jim, > > On 22 Oct 2011, at 03:06, Jim Meyering wrote: >> Gary V. Vaughan wrote: >>> As it stands (without this patch), README-release recommends: >>> >>> git checkout master >>> git pull >>> ./configure >

Re: [PATCH] README-release improvements

Hi Jim, On 22 Oct 2011, at 03:06, Jim Meyering wrote: > Gary V. Vaughan wrote: >> As it stands (without this patch), README-release recommends: >> >> git checkout master >> git pull >> ./configure >> make maintainer-clean >> ./bootstrap >&g

Re: [PATCH] README-release improvements

it of ChangeLog: > > + Don't try to run ./configure right after git pull incase files > + that influence the bootstrap process have changed, move the > + ./configure step to after running ./bootstrap. That does not justify the removal of "make maintainer-clean&qu

Re: [PATCH] README-release improvements

Hi Jim, On 21 Oct 2011, at 15:17, Jim Meyering wrote: > Gary V. Vaughan wrote: >> I made these changes in gnulib-local/top/README-release while making >> a start at leveraging the gnulib release machinery into GNU Libtool, >> but they seem generally applicable too. > >

Re: [PATCH] README-release improvements

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

Re: [PATCH] README-release improvements

Hi Gary, > 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 you

Re: [PATCH] README-release improvements

Gary V. Vaughan wrote: > I made these changes in gnulib-local/top/README-release while making > a start at leveraging the gnulib release machinery into GNU Libtool, > but they seem generally applicable too. Thanks for the suggestions. However, it's not quite ready. > Okay to pu

[PATCH] README-release improvements

I made these changes in gnulib-local/top/README-release while making a start at leveraging the gnulib release machinery into GNU Libtool, but they seem generally applicable too. Okay to push? (NOTE: I doubt this will work with `git apply-patch` since I pasted it together from bits of manual

Re: Slight simplification to README-release

ss its self-tests. So, if the developer > is not yet in the phase where releasing is appropriate, he will > waste time by doing "make distcheck": because "make distcheck" > will take some time running "make dist", "configure", and "make", &g

Re: Slight simplification to README-release

Reuben Thomas wrote: > the expectation is that you already have all tests > passing before you start the release procedure. Exactly. It makes no sense to work on the packaging details of code that doesn't even pass its self-tests. So, if the developer is not yet in the phase where releasing is app

Re: Slight simplification to README-release

On 6 October 2011 00:54, Bruno Haible wrote: > > In a big package, "make check" will take, say, 10 minutes and > "make distcheck" say 30 minutes. When I'm preparing a release, > it takes me at most 1 or 2 iterations to get "make check" work > fine, whereas often it takes me 5 iterations until "mak

Re: Slight simplification to README-release

Hi Reuben, > Anything that reasonably reduces the number of manual steps here has > to be a good thing. I combine two sets of make targets: > ... > +make check syntax-check distcheck But that's probably not how people actually do it. In a big package, "make check" will take, say, 10 minutes

Slight simplification to README-release

-release. + * top/README-release: Combine two steps. + 2011-10-05 Bruno Haible Tests for module 'fmodf'. diff --git a/top/README-release b/top/README-release index 0299c82..cb7c0b7 100644 --- a/top/README-release +++ b/top/README-release @@ -22,10 +22,9 @@ Here are most of th

Re: Typo fix for README-release

Reuben Thomas wrote: > diff --git a/top/README-release b/top/README-release > index 69841d2..0299c82 100644 > --- a/top/README-release > +++ b/top/README-release > @@ -40,7 +40,7 @@ Here are most of the steps we (maintainers) follow > when making a release. > # "TYP

Typo fix for README-release

diff --git a/top/README-release b/top/README-release index 69841d2..0299c82 100644 --- a/top/README-release +++ b/top/README-release @@ -40,7 +40,7 @@ Here are most of the steps we (maintainers) follow when making a release. # "TYPE" must be stable, beta or alpha make TYPE -