On Wed, Jun 27, 2012 at 10:31:01PM -0500, DJ Lucas wrote: > > > I'm afraid a month probably won't be enough time. It has been several > years since a BLFS release. I'm not even sure what year that was now, > but it has been overwritten by years of only basic proof reading by > people perusing the commit logs and the instruction authors themselves. > The entire book needs to be reviewed for spelling, grammar, and > consistency, which is a painful job that few of us will _want_ to do. In > addition to a spell checker and manual reading (out loud), a decent > screen reader works wonders for finding transposed words and odd phrases > (and it gives those of us without disabilities a good reason to test at > least part of the accessibility stack).
The last release (6.3) was in August 2008. It was for LFS-6.3 which had come out nearly a year before. I understand the idea of making it perfect, and I support improving access for those with visual impairment. I'm lucky - my disability doesn't prevent me using a keyboard and mouse, or reading a screen. BUT ... who here has the hardware for screen reading ? I recall that a previous request to add that to the old Live CD failed for want of anyone with the hardware who was able to contribute (google found that earlier this year when I was checking dependencies for one of the gnome-related a11y packages). OTOH, a few years ago I was involved with AmigOne linux : there was a late-2.4 kernel for that machine, with all sorts of weird and wonderful hacks, but kernel development was on 2.6. I did manage to get some patches for 2.6 together, but in the end my machine died (its shutdowns while compiling gcc turned out to be caused by the CPU overheating, and happened once too often). The other people there were fans of the amiga, for whom linux was an intermediate OS until OS4 or whatever it was called was ready. I became used to the phrase "it will be ready when it's ready". When I left there, the Amiga OS was still described as "nearly" ready and the hardware was already obsolete. Striving for perfection is the enemy of good enough. I'm in the 'good enough' camp. > > If we freeze LFS, then I think we can mark BLFS with an entity like > > &lfs_72_checked; and have it display -rc1 while we are in freeze and > > then at release just change the definition. > Actually, the original plan was to make it empty at release if we are > going for a matching release version. I don't know if this holds true > today. Also, in the old days (it was sooo long ago), we had waited for > LFS final, then freeze. BLFS would lag behind LFS by at least a couple > of months for final commits and cleanup. I don't know if we should > follow the old way, but figured I'd throw it out there. I think that the BLFS book was originally much smaller than it is today - compare 5.0 in the archive. If it has to be nearer to "perfect" than I prefer, reading all the details will take a very long time. Meanwhile, the world marches on. The more a release is delayed by polishing the contents, the more it will be out of date, and the harder it will be to explain why anyone would want to read it instead of using the development book. > > I suspect that packages that must be changed during freeze would only be > > due to bugs or security issues, not enhancements. Generally, if a > > package is major.minor.patch and only the patch level changes, updating > > does not affect other packages. > Personally, I'd suggest branching at package freeze time, and back > porting changes from head. I realize that is extra work for whoever the > RM is, but the one thing I really do not like to see is somebody sitting > on a big commit for a month or better because of a package freeze for > release. That is really frustrating from a peon's POV! We seem to have a > pretty good editorial team now, maybe a little rough around the edges, > but for the most part we are tolerable of each other and work pretty > well together. I'd like to see some of the (not so) new additions stick > around for a while. :-) For BLFS in its current form, I think branching is the wrong approach. If we have a *short* freeze, only essential changes will go in and there is a good chance that they will not break other packages. Branching is viable if somebody is going to commit to maintaining the branch for some time after its release, e.g. with updates and point releases to fix vulnerabilities. I don't see any enthusiasm for that. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
