Re: another gnulib update

[Gary V. Vaughan]

Hi Jim,

Thanks for the swift response.

On 25 Feb 2007, at 12:48, Jim Meyering wrote:
> "Gary V. Vaughan" <address@hidden> wrote:
> > For this reason, and for the difficulty of reboot-strapping old  
> > releases
> > of gnulib using projects, I find the anti-release model of gnulib
> > somewhat
> > depressing.  It would be nice for gnulib to make occasional feature
> > freezes,
> > or release branches, or to maintain stable and development  
> > branches, or
> > otherwise to provide time for testing and stabilizing some version of
> > the
> > gnulib codebase every now and again.
>
> Hi Gary,
>
> That's not necessary.
> Instead you can check out a copy of gnulib using the release date
> of the package in question (cvs co -D '2007-02-24 18:43:15 +0000'),
> then bootstrap like this:
>
>     ./bootstrap --gnulib-srcdir=/gnulib/snapshot/for/m4-x.y
>
> That's why yesterday's coreutils-6.8 announcement included
> the relevant snapshot date/time for gnulib:
>
>     This release was bootstrapped with the following tools:
>       Autoconf 2.61a
>       Automake 1.10
>       Bison 2.3a
>       CVS Gnulib sources from 2007-02-24 18:43:15 +0000

My problem is that I don't know how to pick a snapshot date that
will include recent fixes to modules M4 cares about, but not
destabilizing changes that occured in the same timeframe.

I'm thinking about making an effectively local branch of gnulib as
M4 releases approach so that I can manually apply just the gnulib
patches that matter to M4 without accidentally picking up one
of the module reorganizations patches that occur in gnulib
relatively often.

With luck, between forking a gnulib snapshot in preparation for, and
actually making the release, no relevant gnulib patches occur, or if
they do they don't fall in the same timeframe as one of these module
reorganizations... in which case your method works admirably. Equally
likely is the scenario where M4 freezes for release testing, but then
bugs in relevant gnulib modules are found and fixed in gnulib -- either
by M4's testing, or else independently.  Rolling M4's gnulib snapshot
date forward by a week or three to pick up those changes at this
point will likely also pick up destabilizing patches that happened in
the same timeframe.  In the absence of (even transient) stable gnulib
releases, I think the only way to manage this sanely is to maintain a
per M4-release gnulib fork in the weeks leading up to that release,
so that when M4 release testing is complete, and patches inspired by
that testing have been applied put out a pseudo-release gnulib tarball
massaged to support that M4 release.

Is there perhaps some way to cleverly tag the CVS tree of gnulib to
avoid this problem?  I don't see any other way to approach it than to
provide the equivalent of a stable and development branch of gnulib :-(
M4 uses a relatively tiny number of gnulib modules, so the problem is
surely exacerbated as projects use ever larger subsets of gnulib?

Cheers,
        Gary
--
  ())_.              Email me: address@hidden
  ( '/           Read my blog: http://blog.azazil.net
  / )=         ...and my book: http://sources.redhat.com/autobook
`(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912

PGP.sig
Description: This is a digitally signed message part