a few decisions

James Robertson jwrober at linuxfromscratch.org
Tue Feb 1 07:29:52 PST 2005

Jeremy Huntwork wrote:
> Hello Everyone:
> 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.

I hope to have my development box finised soon as well.  I need to
finish the docs on the old tool.  I still that is important as well.

> 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.

I knew you would come back, that is why I didn't do anything!

> 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.

Agreed 100% here.  We must have discussion and consensus of what is
going to be coded before it is coded.  Also, I want to see a BZ entry
for everything.  This means that every commit message should mention a
BZ entry it is associated with.  This does not mean that the commit of
code has to close a BZ (unless it does), but should reference it.

> 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.

Agreed as mentioned above.  You will also see that the SRS and work
associated with the new ALFS all centers around BZ entries.  This is
extremely important IMHO.

> 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 
> coders are.
> 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.

+++++1  On this.  I think everyone knows where I stand on this issue.
It will really help down the road y'all.  I know many coders that just
jumped into the code 'cause that is what they like to do and ended up
having to re-code becasue requirements were not well known enough.

> 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 
> alfs-discuss list.
> 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.

No apology necessary.  Life happens.


More information about the alfs-discuss mailing list