On 2/17/2010 6:32 AM, Randy McMurchy wrote: > > If the community's expectations are that we have the most current > release of every package in the most recent BLFS book, then the > expectations are too high and are unreasonable. > > Do you really think there will be that much difference between > GNOME-2.28 and GNOME-2.30? Enough to say BLFS is "out of date"? > > I don't think so, but that is just one man's opinion. > > This is the main sticking point for releasing a BLFS that I see...Just my thoughts on the subject but Ill' throw them out there.
I've never spoke up but every time the "BLFS Release" discussion comes up I think "Targeted Version Freeze". At some point, maybe in the LFS release cycle, define the versions of major package groups that will be targeted for BLFS and branch. Only allow security and well reasoned updates that exceed the the targets into the branch. I'm not talking about every package in the book, just the major items, KDE, Gnome, Xorg, Mozilla apps, etc. Most of the other common apps are at least feature stable and don't generally cause an upheaval when they make new releases. But trying to ensure support for KMS or yesterdays newly added codec in FFMPEG is a fools game - let it stabilize in the wild first and the project dev's can take care of the growing pains. So often, I see DJ and a few others, working so hard through some very involved package groups only to immediately move on to the next release. Not a dig at DJ, he does great work and works hard. But I think it would be a little more relaxing if he had a defined target, rather than trying to keep up with so many divergent projects. After stabilization and release, trunk will take off again and maybe have to skip a release for some packages - but at least there won't be all of this work going on that is just replaced before it ever sees release. i.e. - Defining a target of the current stable gnome, kde, and xorg, this will indirectly define minimum versions of most supporting dep's included in the book. And work can go into stabilizing rather than version chasing. Another idea is to not worry about versions at all. Only build test and update packages as required to maintain parity with LFS and security errata. It may not be bleeding edge but it would certainly meet the educational goal and provide a usable system. Major updates could still be done as it it makes sense to do so, feature-wise, not just because the external project made a release. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
