Narrowing it down [Was: Name for the new tool]

James Robertson jwrober at
Sun Dec 19 18:53:26 PST 2004

Jeremy Huntwork wrote:
> James Robertson wrote:
>> I am still completely confused as to why you keep saying that it is 
>> not the second version of anything.  What am I missing that you guys 
>> are talking about on IRC that is not making it to the list?  The SRS 
>> makes it very clear that nALFS2 (as it is called there) is the logical 
>> progression of the tool, hence the 2 in its name.
> The SRS is incorrect and hasn't yet been changed. See my note below...

Why did no one tell me then?  I worked hard on that piece of doco.

>> What is all this stuff about not using any code and starting from 
>> scratch and using what ever moongoo is.  AFAICT moongoo is a POC of 
>> using the book as profile and nothing more.  I am not interested in 
>> the simple syntax to describe the build commands or anything else that 
>> is being concocted in there.
>> Someone either needs to edit the SRS from scratch to get this stuff in 
>> there so we can talk about it, or quit saying anything about it.
> James,
> That document got started in August. At that point we didn't have as 
> clear of a direction in mind with what we were going to do. Since then, 
> it has been realized, with the various features listed, that we're going 
> to be building this thing from scratch. (That at least should have been 
> apparent by the discussions of which language to use to code it.)  

Language choice has and should never have any berring on the 
requirements laid out in the SRS.  The SRS is by definition code 
agnostic.  Any developer with the brains and know-how should be able to 
take the SRS and follow-up details to write the app in any language 
he/she sees fit.  I still do not see where this was discussed.  It was 
not clear to your doco guy.

> The 
> tool has only continued to be called nALFS2 in the docs on the wiki 
> because we hadn't come up with a different name yet.  It's been 
> mentioned here on the lists several times so it's not a matter of things 
> we are deciding in IRC.  I haven't made any major decisions in IRC that 
> I haven't also written to the lists about.

I should have probably posted a new thread.  This really has nothing to 
so with the name selection conversation.

> Yes, we *are* looking to do the same thing that nALFS did, in that we 
> are hoping to create a tool that automates the building of LFS. And yes, 
> if we had continued development with nALFS many of the features would 
> have been considered for inclusion as a natural progression. But again, 
> and for the last time, nALFS2 will *not* be the tool's name for the 
> following reasons:
> 1) 'n' no longer fits. It stood for Neven Has and *his* implementation 
> of ALFS. Neven is no longer with us, and we are not going to be using 
> any of his code, there is no need. Even if we did end up using his code, 
> a note can be included in the sources of our tool that gives him proper 
> due.  Moongoo started out as a POC, and in many ways it still is. 
> However, it also makes for a good base for the new tool that we want to 
> build.  At this point, we can begin adding support for the other 
> features we mentioned.

I am ok on this point.  If you guys feel a completel rewrite is in order 
that is fine.  I'll bet you will use some of his code and your comments 
about providing kudos to him in the code is fine by me and meets the 
GPL's requirements.

> 2) nALFS was just an implementation of ALFS. One of many ways that it 
> could be done. We are now going to be creating an official 
> implementation, with a team of developers, distinct and different in 
> numbers of ways from nALFS, so that there will be few similarities.

nALFS _is_ the current most supported and feature rich implementation of 
the ALFS DTD syntax specificiation.  It _is_ the current official 
implementation for automating LFS builds for the LFS project.  Please do 
not lose sight of these facts.  Neven started and Kevin continued in 
this vein.  Both of them did a very good job during their time.  We have 
all known for quite awhile that nALFS in its current form needs a lot of 
work to move to a second generation model.  The DTD needs an update to 
support this as well.

> 3) nALFS as a tool name was confusing. It only made sense to those who 
> dug around the project for a bit.  It's in that same light that I 
> realize it is not such a bad thing to have the tool name be the same as 
> the project name. After all, it is the entire purpose of the project to 
> provide an official way to automate LFS builds.
> Therefore, as of today, consider the name of our new tool to be, simply, 
> alfs.  It sadly lacks any flair or imagination, but it correctly 
> associates itself with the project and with LFS and is generally more 
> official in its sound.  Discussion about the name is finished.  James, 
> can you see about adjusting our wiki docs to match, please?  I would 
> also like to hear some suggestions about the best way to number its 
> versions, so we can have that in mind from the start.

alfs as a name is wonderful.  Thank you for the decision on a name.  I 
will update the SRS post haste.  I like sexy names as well, but they 
really did not fit in this case very well.  Maybe next time or another tool.

> Boris, wait a bit yet, please, before you move anything in subversion. 
> I'd like this next week to be used to fully hash out and fill our docs 
> on the new tool.  Jamie, Boris, James, Matt and Manuel can you all 
> please take a final look at our wiki, add anything that you can that is 
> unfilled in the SRS (there's actually a good amount yet) and raise any 
> outstanding questions on this list.  Let's try to have this done by next 
> Saturday, if possible. (I realize the holidays are coming quickly, so 
> the earlier the better)

If we are really starting from scratch, then we MUST get everything that 
  nALFS does it its current version mentioned as a feature in the SRS. 
I did not write any of that in there because I was under the impression 
that we were going to just move forward on the same code base keeping 
what already works.  I will do my best with the Christmas holiday coming 
up.  My wife is very demanding during this season of the year, so my 
idle time in the evenings will be sparse.

> Once we have those docs finished, we can move any usable code from 
> moongoo to the new alfs spot in the repo.
> Thanks everyone,
> -- 
> Jeremy Huntwork

Thanks Jeremy.  I re-read my words while responding and realized that I 
came across very harsh.  That was not my intention.  That is the nature 
of email sometimes.  I have no real objections to "starting from 
scratch" so to speak.  I am not a coder, so it will not effect me in any 
way until I try to use the new system.  We really have to sit down and 
think about what all the current tool does both from a visible client 
and from a back end XML profile parser and workhorse.


More information about the alfs-discuss mailing list