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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
|