Narrowing it down [Was: Name for the new tool]
jwrober at linuxfromscratch.org
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.
> 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.
> 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
> 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