-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/23/2010 06:52 PM, Randy McMurchy wrote: > William Immendorf wrote these words on 02/23/10 13:44 CST: >> Well, this is just my opion, but I want to wait until LFS 6.6 gets >> released and then release BLFS 6.6. That's just my idea. > > Well, what is going to happen is a BLFS-6.5. LFS release cycles are > simply too often for us to keep up. Right now the devs have tested > over 75% of BLFS against LFS-6.5. It would be a complete starting > over process to try to go against LFS-6.6. A new GNOME would be out, > we'd never catch up. > Actually, that is not true. We did not have a plan for a stable release AFAIK. I've been building against 6.5+.
> BLFS-6.5 it is. I'd be willing to bet there is not one distro that > has as current of a package base as LFS, why should we try to release > quicker than distro's? > Actually, I had a thought on that, probably not good for this release as I realize that I'm about two weeks late to suggest this. I've not been building by true 6.5. I've been building by: dj [ ~ ]$ cat /etc/lfs-release SVN-20091206 - jhalfs build and updates upon that (including GCC). I haven't gotten around to glibc yet, but I could do that in a few moments. Anyway, what I was thinking, is that we branch at LFS's first RC. In fact, I could start a full rebuild today based on RC. I haven't looked at the rendering scripts on quantum, but how difficult would it be to make the branch render to /6.6, and head render to /dev as it always has. 6.6 always being in flux, but known to be very close to stable. Let LFS determine package freeze for BLFS (baring any issues with current package versions and LFS-stable). Seriously, LFS has got to be deemed stable somehow, right? Why not cross development between the two by fully testing LFS with BLFS? The reason why I suggest having two branches is for devs that happen to be working on more intrusive changes at the time of the call for stability...for instance, I have fuse, ntfsprogs, pulse, GNOME_CONFIG, OOo etc in the works that I just can't trash right this second to work on stability, however my former 'stable' BLFS can go now, so I could start a rebuild tonight. I figure most of us have our own build scripts. If managed correctly, I'd guess that we could all do a rebuild and deem BLFS relatively stable pretty quickly. Yes I'm proposing that we never release a truly 'stable' BLFS again (stable==static), but that's certainly no worse than where we've been for the past few years. I mean, with the exception of a few minor issues in my earliest postlfs scripts, I could reproduce this system with very little manual intervention, in about 24 hours (3 days realistically) with current LFS. I'd be happy to share my scripts with everyone (but I doubt they'd be welcomed by a very independent group of hackers ;-) ). BLFS just doesn't take a month to build anymore, so it's just not that big of a deal to do a full rebuild, but maybe that is only me. - -- DJ Lucas -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iQIcBAEBAgAGBQJLisgMAAoJEIUM+xKzBYsI7YAP/jF7lZjmeL2Ts21k7/muFoRb KXxYyGiQEvka7chpv6o7h2cx/af5LrrCPligoZR1eIlRR+nkHIHRCtije3nf+QZG T26SM5xY+y+jPQzgUMQs/umQkQdG+zgRSvokXktze+U3F3J1BOczTEPMCurfjHkA Dll77ETyiGaOz9Kf6MvjomzxzUPC3z5Xl2Y/WdvEeRifTLdWCRlv1K8s7r/Fn8VN kPUvHASQPTz+tP+apm9KzEBt+GvOCAbVoclaelsG5arR3NOS8Alte4806QF9rTdI IgM7b3C2IgKiwjqEDMeoI2+EHqKMhk7sDaQIQpCggOXzof2nsxVed0YXLITgZHI4 blgcajYTSR22rzhw3vNkHkZpBXpk/4to4B2QnO2vWVVWKLbRHPQnQrleKFhu7nvq aaX1L6+T+mvA0k6t20+i87lUqntdgYiJjDXNEyBLujGzx0LRf84sVWe7BD5r7WOQ adhtwv+UsH+HwX5E53FwVa7cAx5t0vrssq1yfTiT3t7VhtzvNm4eUN4+UWTp28CE hpn8GEu+uHRoK6DfrLPCdgb/KLSSZqHAF/auAv1AzVq77phRrWjAEWlEQ91y0rhz eO/91cm1FPd3c6oYYlxj98qwnmOLcwwY87H12et5PZ1t69Jil+vf7mgjpIJBCglE n4wrGmM3qOrEuh/mNzPO =wBjA -----END PGP SIGNATURE----- -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
