ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: So, The Show Must Go On
Date Thu, 18 Jan 2001 20:21:29 GMT
At 08:30  18/1/01 -0800, Simeon Fitch wrote:
>Just thinking out loud here, but....

kewl a RT (Random Thought) ;) 

>I'm thinking that it might be  a really good idea if the contents of some
>of these emails where extracted and checked into some part of the cvs tree
>so that there is some centralized point for people to reference. I'm
>talking about something even more informal than the approach I've taken
>toward recording people's ideas in the antidote/docs directory; just a
>place for the brainstorming to be better recorded than in the disorganized
>mailing list archives. 

Agreed _ plan to enhance the FSD submitted by Wolf a bit back this weekend
when I get some free time ;)

>For those cases where full design proposals have already been submitted,
>the key points can be placed in this document, with references to the
>source. Since this is brainstorming, anything is allowed: requirements,
>designs, implementation approaches, whatever. The focus is getting the
>"mindshare" represented by this group recorded and in a format that
>accomidates review and revising.

Right - I would prefer more a functional document as this is less
controvertial and allows us all to concentrate on what rather than how ;) I
attached a reply I made to Jon ages ago. I believe the only modification
was for the point that

* move to anakia/stylebook for docs

which believed should go to the controvertial points. Thou I believe this
was only for documentation internal to each task and stored in .tsk file.

>The initial rule would be that you can't delete what anyone else has put in
>the document, but you can reorganize it based on topic. Further more the
>sections would be somehow labeled according to author(s). I recommend that
>sections be grouped according to topic, e.g. all the different approaches
>to properties handling be group together, cronologically, with commentary
>about the pros and cons of each approach, and proposals that include the
>best parts of the previous proposals.

I don't think we can section of ideas by author because in a way there is
many people who are authors to concept from users to developers. ie
Consider the case of the workspace concept. Originally it was asked for on
ant-user, Sam Ruby was the first to crystalize it and express a name for it
(System level build files), I applied psych101 and renamed it to Workspace,
Matthew Foemmel was the first to turn it into something useful (AntFarm
proposal) while JDD was the first to formalize it into a common use case
(his workspace/module proposal). So in all - I think I would be -1 on
anyone claiming authorship over certain points as for most cases (given
simple example above) the answer to who "owns" the idea is a lot of damn
people ;)

>Another benefit to this is that it will allow the best parts of each
>proposal to be better collected so that say one person's property
>architecture can be combined with someone else's task execution engine,
>etc. 

I don't really think we should do this - at least yet. Most of them have
similar arrangements. Consider properties architecture, all of them are
hierarchial to some degree, AntFarms difference is that it also has
namespacing for variables, AntEaters difference is that it is string only
while both Frantic and Mymidon are identical and similar to the others
minus the differences.

Frantics the only one with a *different* task execution engine (ie the
tasks do it them selves) but the others are broadly identical but
structured differently.

I guess my point is that describing code is not really relevant until we
can describe the functional requirements as many of the proposals do the
same thing - just differently ;)


---------------------------------------------------------------------
At 11:30  18/12/00 -0800, Jon Stevens wrote:
>on 12/18/2000 10:59 PM, "Peter Donald" <donaldp@apache.org> wrote:
>> What makes you think that the current ideas about Ant2.0 product is a
>> mishmash. I think the aims/designs are relatively clear - the
>> implementation is completely fuzzy but there is little use hashing it out
>> when only one of the developers who is proposing a revolution is present.
>
>Ok, where is a single clear well defined functional specification for Ant
>2.0 that everyone agrees on? Sorry, I missed it.

Mime
View raw message