Udev in b6_0: to be or not to be

Matthew Burgess matthew at linuxfromscratch.org
Tue Jun 1 14:45:31 PDT 2004


On Tue, 1 Jun 2004 16:33:59 -0500
"Larry Lawrence" <larry at linuxfromscratch.org> wrote:

> 
> "Matthew Burgess" <matthew at linuxfromscratch.org> wrote in message >
> > What would you rather us do then Larry?  Simply stop all development
> > 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 kind of stagnation that has occurred in the past.  Now you're
> > saying, steadfastly, that this can't happen because we shouldn't be
> > able to pull things out of the testing branch if it is deemed
> > insufficiently stable? How else are we to get the developments from
> > HEAD available for a wider range of testers, while still allowing
> > HEAD to progress?
> >
> > Thanks for any constructive comments,
> >
> > Matt.
> 
> We are probably defining Testing differently.  I treat Testing as "LFS
> as a whole".  Is the unit working to produce the correct results (i.e.
> teach, stability).

That's what I envisioned the "stable" branch to be - i.e. once it's in
stable, there's essentially "no going back" - only minor
wording/spelling/grammar adjustments are made at this stage.

> Package selection is happening when it moves from unstable to testing.
>  The reality is that when a package moves, it
> will never get kicked out, patches will be applied as is favored in
> this example.  I see this as the stage where wording is refined, order
> is confirmed and release awaits time and adjustments from feedback.
> 
> I am understanding that your Testing is a selection that you feel a
> greater number of people will 'build' exposing problems unseen in
> HEAD. I hope that's correct.  That may or may not be true and I have
> no basis for arguement.

That's the way we'd like to see things happen, yes.

> There are a great deal of community members building unstable which
> limits those that come in just to build test. One concern I have about
> this is that your additional builders are probably people that should
> be building stable, leading you to determine if bugs are package
> combinations or build mistakes.
> 
> Based upon the reports I'm reading here, I think the HEAD team is
> doing an excellent job of reaching, developing, and contributing to
> the greater Linux community.  I would think stopping HEAD from going
> forward would stop development, that is something I would not
> advocate.

I can't agree strongly enough :)

> I do envision longer time periods between the advancement and when
> they enter the book then most of the community.  There is not a
> correct period of time that can be predefined, but rushing gives me
> concerns of appearing foolish.

Again, please bear in mind the long period of stagnation that preceded
all of the BE-LFS work.  Although it looks as if a lot of the changes
are being rushed in, they have actually been fairly well tested for a
considerable time, just outside the vision of these lists for the large
part.  Just the other day, a comment was made on IRC as to what HEAD
should be tackling next - it doesn't look like there's anything on the
immediate horizon that we would want/need and is even remotely
stable/usable enough to put in HEAD!  I think the big change we're
wanting to see get underway is gcc-3.5/4.0, but that's a considerable
way off at the moment - heck, upstream can't even decide what version
number they're going to christen it with :)

> I am generally better rewarded for patience.  Enough philosophy. 
> Hopefully, this will clarify some of our differences.

Indeed I think it does.

Best regards,

Matt.



More information about the lfs-dev mailing list