Udev in b6_0: to be or not to be

Matthew Burgess matthew at linuxfromscratch.org
Tue Jun 1 15:01:57 PDT 2004

On Tue, 01 Jun 2004 23:54:06 +0200
Jeroen Coumans <jeroen at linuxfromscratch.org> wrote:

> Matthew Burgess said the following on 01-06-2004 21:19:
> > 
> > like has been done in the past?  I'm confused.  We *need* constant
> > development in order to maintain inertia in the project and prevent
> > the
> Here's what I understood about the new LFS development model:
> Former LFS development model:
> * CVS branch gets new development
> * when CVS is stable enough, put out a testing release
> * when the testing release is stable enough, release it
> New LFS development model:
> * unstable always gets new development
> * testing pulls from unstable, making it ready for stable
> * when testing is stable enough, release
> What you describe is very much like our former development model. It 
> would require a "stabilising" of CVS HEAD (unstable), very much like
> we have now. New development, like integrating a new glibc (if there
> was any), is out of the question right now. Thus, development has
> halted until a testing release is created.

What happens (or is intended to happen) is that work goes on in unstable
until a particular feature is at a relatively stable point (e.g. a new
toolchain combination). That is then tagged in CVS, ready for the
"testing" branch maintainers to pull down as and when they deem
suitable.  Meanwhile HEAD development is still continues on, knowing
full well that it is not affecting "testing"'s ability to pull down the
last-known-good state. Obviously, working on more than one major change
at a time is likely to decrease the chances of reaching a suitable
stability point, hence the assumption here that, by and large, HEAD will
concentrate on one feature at a time.



More information about the lfs-dev mailing list