Jon Stevens wrote: > > on 12/9/2000 1:36 AM, "David Li" <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > I am new to Ant list. I have written a couple taskdef for Ant 1.2 that > > I'd like to contribute to the community. How do I go about doing this? > > Thanks. > > > > David Li > > DigitalSesame > > Start off by describing what it does?
David, Correct me if I'm wrong, but I think what you are looking for is some more guidance on how to effectively volunteer your efforts to the Ant project. Below is a copy of a write-up it did that was originally posted in the message (http://marc.theaimsgroup.com/?l=ant-dev&m=97542387718883&w=2). Some of this is just my take on things, but you will find the URL to the official guidelines below. ------------ For getting your submission into Ant, here are the general guidelines (Antidites, correct me if I get any of this wrong). 1) Read *everything* at http://jakarta.apache.org/site/guidelines.html and the five links listed there. 2) Before submitting your patch/addition, make sure you have the /very/ latest version of the source and that your change compiles and works with it. 3) Make sure your code is propertly documented in JavaDoc format, the source files have the correct copyright header, and that the code basically follows the Sun coding conventions document. 4) Make the appropriate changes and/or additions to the documents in jakarta-ant/docs. 5) Update or add, as appropriate, to the test code in jakarta-ant/src/testcases so regression testing can be applied to your offering (and ensure you haven't broken anything). 6) Create the patch file with "cvs diff -u" and post it to the group along with a jar/zip file containing any new files that you have. Please create the zip and the diff relative to the jakarta-ant directory so it is easy to apply your changes, particularly new source file locations. Post all this to the group with the subject starting with [PATCH], and include a full description of what the patch is, why it's useful, and why people should test is out for you (the sales pitch). 7) Be patient. One of the committers will have to apply the patch, build it, and test it. The committer may solicit help from others in the group on this, particularly if the patch involves proprietary tools that the committer has no access to. The committer may also request modification so that the code better fits the design or other constraint. You also have to be prepared to accept a negative vote on your submission, for one reason or the other. This is where the discussion gets interesting, and where you have to keep and open mind while at the same time being an advocate for your offering. Remember that the discussion isn't about your intelligence or technical prowess, but about the suitability of functionality you offer or the design approach you used. It is meant to be a constructive and objective discussion (ideally, anyway). 8) If you make subsequent changes to the patch before it is committed, your continued submissions should still be differences based on the latest version of the code (i.e. don't diff your diffs). This is no big deal since that is what "cvs diff" gives you anyway. Just make sure you include your new files each time. 9) If a week or so goes by and there is no dialog on your submission, don't assume that people aren't interested in your work. Just send a polite email asking if anyone has had the chance to look at it, referencing your original post with a link to the mailing list archive. Due to the voluntary nature of the project, it is easy for submissions to drop through the cracks accidentally. It is no means a commentary on your work. I hope this helps, and gives you a better feel for how to make sure your contribution is best offered. sim
