On Wed, Mar 08, 2006 at 01:36:37PM -0600, Bruce Dubbs wrote: > It is time to start considering a new LFS release.
Not yet, IMO. We have 3 branches, 2 in a state of flux. If we go with trunk or alpha we release with a really old kernel with security vulnerabilities. udev_update is really the only branch that has package versions worthy of release. However, it isn't ready yet as udev and the kernel are still moving rather quickly. To revert now would still require a newer version of the kernel than exists in trunk as well as security patches. This gains us nothing as basically it would be the same as another branch whether it is done in trunk or not. After udev_update merges into trunk, then we have to decide on the alpha branch or not. Merging alpha the same day as merging udev_update would be apropo provided an ICA test still verifies it, so I don't see alpha slowing us down any. > I see that we are behind on gcc and glibc as gcc-4.1 and glibc-2.4 have > been released. > > The kernel is about to release 2.6.16 (they have been on 2.6.16-rc5 for > about two weeks now) so we are quite a bit behind there. What's the hurry? Who are we competing with? I'm not trying to be defensive, but trying to sort out your reasoning. We all want a release, but that should have happened a few months back. It just isn't ready right now and a rush job is not a good idea. > I'm not sure what the status of the udev branch is. I haven't seen much > activity there for a while. Read lfs-book, please. Bugs are being tracked and commits are being made with more sitting in at least 2 sandboxes that I know of. > The reason I'm asking is that BLFS needs to go into a different mode to > get out a companion release and there have been a lot of significant > updates including X, Gnome, and KDE since the last stable release. That > includes rebuilding all the packages with the latest toolchain once that > gets frozen in LFS. CC'ing to blfs-dev: In the last couple weeks I've found a few packages that hadn't been updated in a while in BLFS. Unfortunately, I've been busy and am currently out of town. What little time I spend on the computer each day is being utilized for udev testing. Could you perhaps provide a table in your homedir or on the main site somewhat like this: Package Build Minimal Runtime Testing Extensive Runtime Testing --------------------------------------------------------------------- popt verified verified not verified <..> This would help everyone, especially developers, see at a quick glance what is still needed. From my perspective, upgrading packageX that is untouched since 6.1 is vastly more important that upgrading packageY that has seen at least one version bump since 6.1. Just as an aside, should net-tool's patch, even if it works as-is for gcc-4, still be called gcc343_fixes (or whatever the exact name is)? -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
