On Sep 4, 2007, at 4:53 AM, jean-frederic clere wrote:
Hi,
I would also propose that we take an handling of release branches
similar to httpd.
The release branches are:
/tomcat/tc6.0.x/trunk
/tomcat/build/tc5.5.x/
/tomcat/container/tc5.5.x
/tomcat/jasper/tc5.5.x/
(Note it uses /tomcat/connectors/trunk)
/tomcat/build/branches/tc5.0.x
/tomcat/container/branches/tc5.0.x
/tomcat/connectors/branches/tc5.0.x
/tomcat/jasper/branches/tc5.0.x
The votes will get in a file named STATUS file and once accepted in a
file named CHANGES.
The proposal of backports/fixes should be a description of the
feature/PR number and a link to a commit (in another branch or
sandbox)
or a patch (diff -u) against the branch.
A proposal needs 3 +1 votes and no -1 to be accepted. The committer
that
makes the proposal is responsible to commit the new code (and move the
proposal from STATUS to CHANGES) in the branch once accepted.
I'm +1 for this type of procedure, but I don't see how
this can be shoehorned into the current setup and layout
of TC.
The basic ideas behind httpd and apr are:
o There is a set development location (currently trunk)
which operates under CTR.
o There is a set release branch location which only
operates on RTC. All code patches must first be
applied on the development location and then be
proposed for backport and obtain 3 (or more) +1
votes.
The premise is that there is a codebase which is CTR
and thus very free and easy, but it is never directly in
a "to be released" path. All code that is destined for
actual release must be applied to the stable/release
branch via a RTC method.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
