a few decisions
jhuntwork at linuxfromscratch.org
Mon Jan 31 19:52:24 PST 2005
ALFS has been pretty dormant for several weeks now. I know that part of
that has been my stepping down from the project, and I know many of the
rest of you have been pretty busy as well. In my time away, I've been
doing a great deal of thinking and reviewing of where the project is and
I've come to several conclusions.
First of all, since no one ever stepped up for the role of ALFS project
leader, and I again have a fair amount of renewed energy, I am staying
on as project leader, at least for the time being.
Secondly, I really like what has been done, Boris, with respects to the
ability to parse the LFS Book's commands and manipulate them. You've
done excellent work in that regard. However, there is a good deal about
the way that you've been working that I must say I'd like to see
changed. LFS has and always will be, as far as I can see, a
communicative project. It openly welcomes and includes people from
everywhere, and their ideas, opinions and expressions are encouraged (as
long as they do their research! ;) ). And discussion of its future is
not limited to just the active team members, but to everyone that wishes
to participate. To that end the mailing lists are really still the best
medium for communication within LFS. IRC is a very useful tool, esp for
when developers what to talk and discuss amongst themselves. But I feel
very strongly that the community, which really is the life of this
project, needs to be invovled for major decisions.
Therefore, I'm enforcing some guidelines for all ALFS developers:
1) Major discussions will occur on the alfs-discuss list. This isn't
really a new thing, so it *shouldn't* pose any problems for you.
2) Subversion and Bugzilla will both be used for development of the new
tool. These are already in place on the LFS server, and both provide
very helpful functions, not just for the devs, but for *all* who are
interested in ALFS. We need our developers to use these tools.
3) Our developers must be subscribed to alfs-discuss and alfs-log either
via a news reader or email subscriptions.
4) No major concepts or code will go into alfs without it being
discussed and approved on the lists. This is after all, not a tool under
developement by one maintainer, but by a community, however few our
5) I know I have varied on my ideas/decisions about this one in the
past, and I may have even said some conflicting things. However, so that
as many as possible may be involved, and so that our targets and
direction may be clearly seen by any who are interested, we *will* be
finishing up the SRS that James has started. This has top priority on
the list of ALFS todo's. I want a skeleton of guidelines written out so
that everyone, not just the coders, know where ALFS is headed, and how
we're going to get there.
These five areas will be required of all developers of alfs. Of course,
if you have any suggestions on what might work better, you're free to
express them here on this list, I will listen to any reasonable objections.
I'm posting this to lfs-dev as well, because I'd like ALFS to receive as
much attention and support from the entire LFS community as is currently
possible. To that end, if there are any others who would like to offer
their services to the development of alfs, please let us know on the
Lastly, I want to make a public apoplogy for any confusion that my poor
leadership has brought to the ALFS project, but I very much want to see
it well organized and running smoothly, and I intend to help it along to
that goal as much as possible.
More information about the lfs-dev