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 :-)!).
Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
