unstable branch for LFS

Bill maltby - LFS Related lfsbill at wlmcs.com
Tue Oct 15 06:08:32 PDT 2002


On Tue, 15 Oct 2002, Matthias Benkmann wrote:
> I think with all the changes going on right now with gcc-3.3 and
> glibc-2.3.1 and other unstable packages that will become part of a future
> LFS version (e.g. coreutils) we need an unstable branch of the LFS book.

I agree. But, AFAIK, that is what the current CVS is for. This based on
observation of the numerous revision/test/revise... procedures I had
observed in the past. If my understanding is correct, then I think that
your next paragraph's "...as it should improve upon LFS 4.0 (leading to a
better 4.1) instead of..." should be considered as a new role for the
"current" CVS. Having a branch that receives closer scrutiny, leading
always to near-term improvements, and one that is a "community sandbox",
leading (through "experimentation") to *long-term* benefits, seems like it
would provide substantial benefit.

> The current CVS version cannot fulfill this function as it should improve
> upon LFS 4.0 (leading to a better 4.1) instead of getting lots of unstable
> changes using packages whose introduction to stable LFS lies in an
> uncertain future.
> 
> Without an unstable LFS branch, it will be hard to keep track of the
> solutions people are working out right now. For instance there have been
> several proposals for solving the libnss segfault issue and several
> reports/patches to fix gcc-3.3 issues, but the introduction of the new
> glibc and gcc to the stable LFS book is probably months away and when it
> comes, we will have to dig through the archives to find the solutions that
> are in front of our noses now.

Not if they continue to treat the current "CVS" as the sandbox.
Unfortunately, it would then contain both needed "stable" adjustments for
4.0 users and "experimental" adjustments. This would force 4.0 users to
"filter" when they tried to use the CVS version to make needed
adjustments.

My point, if not obvious, is that reassignment of the role of "CVS" to one
like you suggest, and addition of an "unstable" branch pays benefit to the
community, as you envision.

> And putting new patches into CVS to accomodate a gcc the book doesn't use
> can introduce instability [...]. And putting unreleased packages such
> as gcc 3.3 into CVS is out of the question anyway.

Only if they do not view the current CVS role as appropriate for this sort
of stuff (and I think they shouldn't).

> I believe an unstable version of the book would be a very good thing. I
> don't know what kind of check in rules exist now for the editors but for
> the unstable book they should be very relaxed. If someone mails a patch to
> the list to fix a gcc 3.3 issue an LFS book editor should just be able to
> commit it to the unstable version with no more than a casual glance. If it
> breaks something it can always be fixed later when someone reports the
> breakage. 

For this to be reasonable, it must be known that there are several
"aggressive" users of the unstable branch that will really "stomp" on
things. Possibly even a "semi-formal" regression-test scenario (I don't
think I like this thought) would be needed to assure that all the patches
added with "no more than a casual glance" really are evaluated. Otherwise,
there is a risk some "time bomb" might migrate from unstable to stable.
Right *now*, we seem to have a cadre of "aggressive" users. Will that be
enough?

> Unreleased packages, snapshots and CVS versions of packages should be okay
> and in fact preferred [...] be no pressure for the unstable book to
> work at all times [...]

> I'd like to emphasize that the unstable book is not intended to ever
> become stable. That's what the current CVS version is for.
<snip>

I think "That's what the current CVS version should be for" if its now
now.                                         AAAAAAAAA

> MSB
> 
> p.s.: In case someone is confused: [...] terminology would of course
> have to be changed into "stable branch" and "unstable branch" or
> something like that.

Thereby stepping into the mainstream usage.

-- 
Bill Maltby
billm at wlmcs.com

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list