Dead Project? (I hope not)

Matthew Burgess matthew at
Sun Aug 20 09:31:42 PDT 2006

Thomas Trepl wrote:

> 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!

> 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.

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?

I don't see the "don't break the build" mantra of the books as a Bad 
Thing.  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 :-)!).



More information about the lfs-dev mailing list