On Saturday 30 July 2011 02:29:55 Randy McMurchy wrote: > ... > I was hoping that my response to your post would encourage additional > responses. Actually, I am surprised that it has not. All that has > happened is additional packages have been added to the book which is > the opposite of where you suggest we go. I am wide open. Let everyone's > opinions flow! > > I am open to suggestions, let the community speak out! C'mon, we need > to keep BLFS alive!
Oh yes, the topic should cause an agile discussion. I think to come up with valuable suggestions is nearly as hard as keeping BLFS up to date ;-) However, some interesting ideas, opinions and suggestions did came up and to me - speaking for myself - it looks like the following: I hardly think that BLFS reaches a level of complex which is not longer maintainable but in my eyes, the quality standard has grown that high, that it makes a simple version upgrade or add a new package to a remarkable time consuming task. Maybe we cut that a bit - for example, the depenencies of packages is where we should do a review. As I said in another post, it isnt quite clear when is what required, recommended or optional. A package needed because the other package will not compile if it is missing - this package is of course required. But the difference between 'recommended' and 'optional' is not clear (to me) and maybe can merged in one section. Another thing where I'm thinking about is the topic 'Release'. To me there are only two options: Either do releases, which will result in some kind of "stable book"s which can be seen as something that really works fine, but maybe does not use the most recent versions. The development branch will be freed from the trammel of 'it all must work with eachother'. This is the devel-branch and bugs, errors and incompatibilities are allowed to happen. As I'll say later again, that may speedup development and makes it easier to have new versions in the book. But the challenge will be to come to a state wher a stable release could be cut off. Or, the other option, if we will not cut releases, then drop the stable book as it is a (3 years old) *release*. Than rename "Development BLFS" into simply "Beyond LFS book" or so. But when doing so, we also need to drop the demand on 'everything works perfect with each other'. Than I think, it will not be possible to check all the time if pkgconfig will still work when upgrading glib2 from 2.24.2 to 2.24.3 (ok ok, I know, thats a dumb example). But what I want to say is that we should go a bit more in the direction to assume that other pkgs will still work if upgrading. If not, someone will recognize and report that and then this could be fixed. Working on such a ticket is a team issue where it can be discussed how to fix, do this, do that. If you want upgrade a pkg, currently you are more or less alone to find and fix incompatibilities (before you commit an upgrade). Maybe relaxing here could help to speedup in the race with new package versions. Thats a different approach as we must tell the people that we do our best to keep everything working, but when it does not, ok, we have warned you that this could happen but will try to fixed that. You see, I like the 'bleeding edge' thinking - everything is quite uptodate, but because of that, it may not work proper. So be it ;-) But what IMHO will not work is to live at the bleeding edge AND keep it stable. I still didn't come to a decision on whether I like or not the idea of splitting the book in more (more or less independent) parts. But I feel thats an idea which is worth to think about. What I would not like so much is to transform the book into a wiki. I believe that there will be too much efforts to keep it structured which is automatically done using the docbook. Learning the latter is not that hard. That does not address Fenna's idea of doing a full restart and keep what we have in a wiki (or whatever). The idea of doing a restart from scratch is cool as it may offer the option to modify the docbook stuff for whatever improvements instead of need to update hundrets of XMLs. Another effect could be that we could see, where people are really interested in. Just another 2 cents, -- Thomas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
