zarniwhoop73 at googlemail.com
Sat Jul 18 15:29:22 PDT 2009
2009/7/18 Randy McMurchy <randy at linuxfromscratch.org>:
> What are our realistic choices?
As my initial suggestion:
1. Give up. Point people to cblfs, or change the blfs wiki
so that anyone can post again. [ not my preferred solution,
2. Consider branching a 6.4 version (following Ag's
suggestion to branch each time there is an LFS release)
3. Follow LFS-svn. Inevitably, this means some packages
are out of date. In some ways, that would be "going back
to our roots" in the early days of BLFS.
I note that you mentioned spending 8 hours a day on
BLFS in the past, I think for many of us, what you contributed
would have taken a bigger commitment than that, so we
aren't going to get close to what was done in the past.
Further thoughts -
If we branch for a release, perhaps each package in that
branch should include a status line on its page - I'm
thinking of things like "doesn't build", "seems ok", and
"untested". Probably other variations too. That might
indicate things which ought to be dropped before the
branch gets to a release (if it does).
I also remember that I was trying to keep my 6.3
system usable, but eventually it got too old (specifically,
firefox2 was EOL'd and ff3 needed newer versions of
gtk, glib, etc). To me, that says that if we can't release
everything, we ought to release the bits which are ok.
I'll follow up with a proposal for BLFS-6.4
More information about the blfs-dev