[RFC] Call for new team leader

Matthew Burgess matthew at linuxfromscratch.org
Wed Nov 10 10:31:01 PST 2004

Jeremy Utley wrote:
> Jamie Bennett wrote:
>> Jeremy Huntwork wrote on 09 November 2004 18:55
>>> On Sun, 2004-11-07 at 19:08 -0700, Kevin P. Fleming wrote:
>>>> For a variety of personal reasons (primarily due to the new business I
>>>> started a few months ago), I am stepping down as the team leader of the
>>>> ALFS project.
>>> Well, since I haven't seen any response to this yet, I figured I might
>>> as well offer myself for the job. :)  I'm willing to get more invovled.
>> I think a clear idea of where the project is going should be the first 
>> priority of any would-be ALFS leader. Are we going to stay in maintenance
>> mode and just do bug fixes or is nALFS2 going to materialise? 
>> Obviously if
>> nALFS2 is in the pipe works then we need to attract coders but from our
>> last initial enthusiasm for nALFS2 showed, when it came to the coding 
>> people went quiet.  
> I definately have ideas for the future of nALFS, however, I'm the first 
> to admit, I'm NOT a coder at all.  IMO, the future of nALFS should be 
> dependency tracking within the profiles, logging of files installed by 
> packages, and a client/server architecture, where a "nalfsd" could run 
> on a central server, and any clients could get profiles one piece at a 
> time from that server.
>> IMO another one of ALFS's biggest downfalls is, surprisingly the LFS 
>> community itself. ALFS and more specifically nALFS should, IMO, be the 
>> common tool used by _ALL_ LFS members who are testing LFS builds. It 
>> should
>> go hand in hand with other tools such as svn as a requirement. It would
>> make comparing builds from various people a whole lot easier if we 
>> used the
>> same tool and the same profile.
> Jamie, I must respectfully disagree here.  You are enthusiastic about 
> nALFS, and that's a good thing.  But, trying to force it onto others is 
> wrong.  I personally didn't like to use nALFS, but I've come around, 
> however, if I'm testing things out, I still prefer to be "hands on" and 
> build everything by hand.  That way, you can watch what's happening with 
> the build much easier.  The thing is, a build should be identical if the 
> same commands are performed, no matter if someone has built by hand, or 
> by nALFS, and some people *DO* prefer to use their own favorite methods 
> of automation (bash scripts, makefiles, whatever the case may be).  
> nALFS is just another tool in the toolbox of the LFSer.
> But, people are starting to see the advantages to nALFS - Jeremy 
> Huntwork is helping with the profiles, and put nALFS on his bootcd.  
> Matthew is starting to play with it himself, I've started to use it.

Well, I will be playing with it...once I can tear myself away from my 
home-grown Makefile based scripts :)

>> Lastly (honest!), I'd like to see auto-generation of the ALFS profiles 
>> from
>> the book ala lfscmd. This could be done with XSLT or some other tool.
> Then, all I can say is, do it!  If you can find a method of turning the 
> book's XML into an ALFS profile automatically, without user interaction, 
> I'm all ears.  Personally, I don't think that can be done right now 
> without more massive changes to the XML structure of LFS itself.

I was thinking about this just today actually.  The problem we have here 
is that DocBook XML is ideal for the book.  nALFS XML is ideal for 
nALFS.  Current XML document descriptors (DTDs) don't allow the two to 
be mixed - you're XML is *either* a DocBook document, *or* it's a nALFS 

That said, DocBook 4.0 should be available as a Relax-NG schema.  This 
allows one to use namespaces within documents, so we can signify, in the 
book, which elements are DocBook elements, and which one's are nALFS 
elements.  I'm not sure if this is a viable solution, as the stylesheets 
obviously won't know how to render nALFS content, but at least it's 
something to look into.

This of course would mean that nALFS/nALFS2 *may* need to be able to 
understand Relax-NG - I say "may" as I don't know nALFS well enough to 
determine what it needs to know about the underlying schema.

DocBook RNG is available in alpha/beta tarballs currently, so I can 
easily start trying stuff out if you guys want?  Maybe it's time to get 
a LFS-rng and nALFS2 branch set up so everyone can see what's going on 
with developments?  Or maybe I'm jumping way too far ahead of myself 
again? :-)



More information about the alfs-discuss mailing list