Udev in b6_0: to be or not to be

Jeremy Utley jeremy at jutley.org
Tue Jun 1 21:24:29 PDT 2004

DJ Lucas wrote:

> Larry Lawrence wrote:
>> "Kevin P. Fleming" <kpfleming at linuxfromscratch.org> wrote in message
>> news:40BCB3B1.5060907 at linuxfromscratch.org...
>>> This is exactly the reason we _wanted_ to put udev and hotplug into
>>> HEAD, so that they could be tested on a larger number of systems than
>>> just the ones that us BELFS testers were playing with. If we didn't do
>>> that, we could only "play follow the leader" and wait for the other
>>> distros to make everything right with the world before we put it into
>>> the book, and the community has said they don't want to go that 
>>> direction.
>> And this is exactly why HEAD should not become test at points in time
>> (usually determined by releases). The differences of opinion really 
>> do come
>> down to:
>> Do you put Unstable into Test when it becomes stable  OR
>> Do you pull Unstable from Test when it proves unstable.
>> The community prefers the latter, something I will probably never
>> understand.
>> Larry
> Guess I don't fall in line with the community either.  Since the 
> begining of the branching, I've not liked the order.  As Larry put it 
> above, with our current branching, the latter is always true.  When 
> the branching thread was first proposed:
> http://archive.linuxfromscratch.org/mail-archives/lfs-dev/2002-October/029091.html 
> BTW, Notice the date....IIRC it was discussed bigtime once earlier 
> that summer, and touched upon several times before that.  Since that 
> time, I had evisioned an acutal unstable *branch*.  

As I'm sure people will remember, this is what I had proposed when the 
discussion was going on to bring BELFS back into the project - an 
entirely separate tree.  The rest of the community wanted us on HEAD, so 
we've worked with that desire as best as we can, dealing with all the 
pain it's caused.

> Items would be pulled from that branch when appropriate and merged 
> into head, all the time keeping head relatively sane.  Once all the 
> goals for the next release have been met, branch and continue on.  
> Unstable can continue on it's current branch, or refresh itself at 
> branch point...or any other time for that matter.

Using existing tools (CVS) this is pretty difficult to do.  You then end 
up with twice the commit work (once when it goes into "unstable", and 
again to move to "testing"), and you have issues of incompatibility.  
Subversion will make it a little bit easier, but it will still involve 
double-commits for the most part.  Only by moving to something like 
BitKeeper can we easily pull individual pieces between trees easily, and 
the license issues make BK an unacceptable solution.

> {IMO}Unstable should not have to be terribly concerned with grammar, 
> or spelling, or punctuation (of course within sensable limits so that 
> it is at least understandable) as unstable should never be pulled 
> directly as release quality material.  Unstable should be a 
> playground, a proof of concecpt if you will, but nothing more.{/IMO}

This is true, and for the most part, those of us working in unstable 
(mostly myself and Zack) don't - we care about the commands and whether 
they work.  The text comes later, as the feature-set is finalized.  The 
issue most people are facing is there's such wide-spread changes between 
5.1 and 6.0 - this is inevitable, because of the amount of time that LFS 
development has stagnated.  Lets face it, the last really 
ground-breaking release was 5.0 and the PLFS build developed by Greg and 
Ryan.  5.1 has been nothing but package upgrades, while much of the 
linux community has moved on to bigger and better things (NPTL, kernel 
2.6, and so on).  BELFS was written to address that, to bring us back to 
where we *SHOULD* be.  The support from certain circles of the community 
has been overwhelming, but the aggrivation of trying to get the approval 
of the ENTIRE community has been aggrivating, to say the least.

> I hope the original BELFS maintainers don't take offense to that, none 
> intended as current HEAD is certainly nowhere even close to how I had 
> envisioned unstable.

None taken, but the original goal of BELFS was to have a system that 
could be experimented with, and used.  It just doesn't make sense if 
unstable is always completely broken so far as to not be able to be 
built - what's the use of having instructions that don't work.


More information about the lfs-dev mailing list