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
outside.
> 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
scripts).
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.
Ciao,
Thomas
___________________________________________________________
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail:
http://mail.yahoo.de
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
