ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simeon H.K. Fitch" <sim...@fitch.net>
Subject Re: [PATCH] Wait and Available
Date Tue, 28 Nov 2000 14:57:29 GMT
On Tue, Nov 28, 2000 at 08:58:46AM +0100, Thomas Christen wrote:
> 
> Since we can calm down the discussion about I or whatever - my question is
> how to proceed. Should I apply the changes my self (e.g. rename the
> Interface, do the formatting with the 4 Blank's instead of Tab's) ? Is there
> someone interest at all ? Is the concept (not the ISupportsTasks !) I
> proposed OK ? Is there a chance to get my posting in to ant ?

There is definate interest in your offerings. It is through such
contributions that Ant has become such a great tool!

I think one of the main issues with the "tabs" (if I remember
correctly), was that your editor was reformatting the whole source
file, making it difficult to determine which changes to the original
you had made, and which were due to reformatting. Although spaces
should be used in leu of tabs, I think the real recommendation was to
turn off auto-reformatting in your editor so only the lines that you
make manual changes to are the ones that show up when you do a 
"cvs diff -u".

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

-- 
Mustard Seed Software
mailto:simeon@fitch.net

Mime
View raw message