Return-Path: Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 70055 invoked from network); 18 Jan 2001 20:28:44 -0000 Received: from mail.alphalink.com.au (203.24.205.7) by h31.sny.collab.net with SMTP; 18 Jan 2001 20:28:44 -0000 Received: from donalgar (d156-ps0-mel.alphalink.com.au [202.161.104.156]) by mail.alphalink.com.au (8.9.3/8.9.3) with SMTP id HAA00475 for ; Fri, 19 Jan 2001 07:28:44 +1100 Message-Id: <3.0.6.32.20010119072129.00945540@alphalink.com.au> X-Sender: gdonald@alphalink.com.au X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 19 Jan 2001 07:21:29 +1100 To: ant-dev@jakarta.apache.org From: Peter Donald Subject: Re: So, The Show Must Go On In-Reply-To: <20010118163052.28748.qmail@web2302.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N 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" 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.