Dead Project? (I hope not)

Thomas Trepl ttrepl at
Sun Aug 20 12:42:48 PDT 2006

Hi Matthew,

>> What I'm missing is the "be"-version we had years ago. This bleeding edge
>> version was where all the fun has been brought to us. From time to time,
>> the beLFS didnt work, had a lot of bugs, typos and all the stuff.
> Doesn't sound like the particular level of quality we strive for in the
> LFS group of books to me!
Hehe, indeed! And there is nothing wrong with. To ensure that the stuff which 
gets published and offered as "official" books will work is ok. But it could 
be pointed out that this is not true for that kind of "book" - it isn't 
really a book, it more like a more or less public sandbox.

>> I'd like to vote for bring
>> up the bleeding edge again - with a quite relaxed commit policy.
>> Why i do think that way?  Because i feel that it is tried to have the
>> development book as stable as possible. Nothing wrong with it, but it
>> lasts sooo long until new versions like gcc-4.1.1 got implemented.
> The reason why gcc-4.1.1 took so long to get implemented was lack of
> developer time - the same reason why the latest stable book took so long
> to get out too.
The gcc was just an example and i'm surely not in the position to do criticism 
on the developers. Viewed from outside, it simply was quite silent.
> Thomas, what specific features would you have in this "bleeding edge"
> version of the book, if one were to exist?  And, why are these not in
> Trac as "Enhancement" style tickets so everyone in the community can see
> your ideas, comment on them, and perhaps even propose patches to see
> them introduced?
Ok, thats an option - I'll create such a ticket. What features such a belfs 
should have? None!  It should simply reflect the newest package versions and 
concepts. For example if we have the new libc-headers recorded in Trac, and 
then? The one will argue that we still have only 2.6.18-rcX kernels,  
no "official" release; the other will say we should wait for glibc-2.4.1 and 
so on. In that time nothing will happen.   ... again: when viewing to it from 

> I don't see the "don't break the build" mantra of the books as a Bad
> Thing.
It isn't! It's quite good and should be fix like a rock and I never will argue 
against it. I just thought for the belfs it could be somewhat relaxed.

> In fact, I think it's very important so that we actually get 
> people testing the new features rather than complaining that they can't
> complete a build. Breakage is allowed to happen - just on the machines 
> that the patch is being developed on.  Obviously, interim patches can be
> attached to the associated Trac Tickets so that Work In Progress can
> be monitored and tested, but the final patch that hits the subversion
> repository must have passed a jhalfs build, IMO (and yes, I know some of
> my recent package updates didn't meet that standard but the bug in
> jhalfs that led to that has now been fixed :-)!).

All in all, you are right, Matt!  And even more, I think LFS is quite healthy 
in the core; there is a issue tracking, quality assurence, qualified 
maintainers, a good infrastructure, innovative development (e.g. the jhalfs 
It's all just a thought. There were good reasons in the past to drop that 
third book - for example because of the more on maintenance and so on. I can 
understand if that would be declined.



Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail:

More information about the lfs-dev mailing list