Mailing-List: contact velocity-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Velocity Developers List" <velocity-dev@jakarta.apache.org>
Message-ID: <3E4802F2.1020802@apache.org>
Date: Mon, 10 Feb 2003 14:52:18 -0500
From: Ted Husted <husted@apache.org>
Organization: Apache Software Foundation - Jakarta Project
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.0.2) Gecko/20021120 Netscape/7.01
MIME-Version: 1.0
To: Velocity Developers List <velocity-dev@jakarta.apache.org>
Subject: Re: [VELTOOLS] Documentation - proposed update
References: <000001c2d132$d7228950$0618190a@amer.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Tim Colson wrote:
> I'm want to help sort things out. And I don't know the best approach,
> but I certainly don't want to stay with a confusing status quo just to
> avoid a couple cvs delete/adds. ;-)

As Nathan mentioned, the best thing is to start with some diffs so that 
everyone can see what you would like changed.

Jakarta, like the original Apache product, works mainly on patches. When 
a change is made, the diff is emailed to everyone who cares. This shows 
us exactly what changes are being proposed (or made).

The underlying premise is that we are all team players here, and we all 
have to do what is easiest for the team. As Nathan pointed out, it may 
be easiest for you to send a tarball, but then everyone watching the 
product has to figure what has changed (or is proposed to be changed).

If you had made the changes in CVS, then there would in fact be less 
controversary, since we would have been sent the DIFFs and could follow 
the changes.

The way things work is fairly simple. You check out the product for CVS. 
  You make whatever changes you would like to the product (or 
documnetation, it all the same thing). When ready, you create a patch 
that shows what changes you would like to make. Most products now like 
these attached to a Bugzilla ticket. If its a controversial change, you 
can post the patch to the DEV list for discussion. If you are a 
Committer, and it's a "typical" change, you can often commit it directly 
and discuss it afterwards (if need be).

The Commons has a pretty good description of the process.

http://jakarta.apache.org/commons/patches.html

-Ted.


-- 
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org