New thread, for what I'm suggesting. 1. Create a branch for 6.4 Something needs to be done to get it to show up on the website, and to render. I've no idea what that involves.
2. Within that branch, label each package (on its page) with a status. Things like: seems ok (i.e. tested on this version of LFS, the instructions work and no problems have been identified) builds, not tested (i.e. not tested in use) not tested fails to build (i.e. for this version of the package) builds, with other problems (I suppose those should be noted on the wiki?) - a tricky concept, it would be easier if I had an example! no longer supported upstream (a bit of a killer - e.g. for the demise of firefox2 in BLFS-6.3 systems) known vulnerabilities, use a newer version if you can For a release, this implies either finding a patch/workaround or dropping this package. 3. Somebody needs to manage the release. I'm reluctant to step forward because (i.) I'm hoping to be away a lot in the rest of the summer, which will delay the process, (ii.) I got fairly pissed off patching old versions of e.g. poppler for vulnerabilities before 6.3 came out, (iii.) I really want to try newer versions of those packages I use in my current builds, (iv.) I want to try some ppc64 toolchain stuff, and (v.) I hate branches in svn as much as everyone else does. [ Actually, that reminds me - if we branch 6.4 then update a version there it isn't a straightforward job to get that back into trunk - ignoring the build size and time which might be inappropriate (just like everything that is currently in trunk, for an LFS-6.5 base) there is the new 'status' field which doesn't belong in -trunk. Releasing when there are _so_many_ open tickets for version upgrades is not a sensible idea. ] But on the other hand, I do have a 6.4 system (packages, and versions, listed at http://www.linuxfromscratch.org/~ken/desktop-2009-06/ ) so I've got experience with some of these packages. Note that my gnome stuff, such as it is, often uses 2.24 not 2.24.3 - I find the point releases are usually only extra translations so I tend to stick with whatever was current when I last looked. If this proposal (for a branch), and my offer to manage its release, is acceptable, I'll be looking to cut an -rc in mid October. That can either include packages with status "untested", or they can be relegated to external links to their home pages. For packages which fail to build and have not been fixed, I guess they'll have to be relegated to external links. Looking at the current book, about 3/4 of it is things I've not tested (I ignore kde3 here because I think it was updated against 6.4). Some of these are things I can build with a DESTDIR install and then discard, others aren't (dependencies on things I refuse to install). So, if I do this then the result will be a smaller book, perhaps a lot smaller). Thoughts ? ĸen -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
