tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <>
Subject Re: Review model take 2
Date Fri, 21 Sep 2007 15:12:28 GMT
I agree with the previous mail that for a while people will be careful to
discuss and review - so probably we don't really need to do anything,
this long thread may have raised enough awareness.

Regarding release numbers - I also agree with you on such a scheme.

My only concern with your last 2 emails: it doesn't address the root
what kind of decision-making should be done in the 6.3/6.5/trunk/dev branch,
on API changes and core features ( i.e. things that will indirectly affect
other people ) ?

It is clear that the previous model doesn't work - any developer submitting
code ( usually valid ),
and then fighting over why a veto is invalid. We do need a way to have core
reviewed by more people and be sure we have a fight-free, polite mode of
expressing 'I don't
think we should do this in the core, please try a different approach - maybe
a plugin, or
a new connector, etc' - without arguing about the actual change itself, just
about the direction
we want for the project. And this should involve more than 2 opinions.

I still think the proposal to do CTR, assuming consensus exists, but on any
sign of disagreement on
a change affecting the 'core' - fall back to RTC ( or request a simple vote,
3+1 and more + than - on
the _goals_, instead of the implementation ). This should also be done
before including new big features
to be bundled in the next release.


On 9/21/07, Jim Jagielski <> wrote:
> Posted on another list, but adding it here with some
> refinements:
> If I had my druthers I'd say we have all release branches
> created and set as RTC. We then follow a release
> number similar to httpd and others where even number
> minors are release, and odd numbers are development.
> We then have a real trunk, using whatever bits and pieces
> of what we currently have and call that TC 6.3 (thus
> allowing for a 6.2 being created from it if so deemed).
> This also allows for patches/code/features to be
> applied in 6.3 and proposed for backport to 6.0
> (again, ala httpd and others). 6.3/6.2 also serves as
> the community testbed for not only new features but
> a plugin/module architecture.
> This can be refined by bumping up to 6.5/6.4 for the
> more future reaching stuff and allowing for a 6.3/6.2 for
> some feature of the old trunk that external projects
> were using/depending on...
> Trunk, of course, would be CTR. Backports and release
> branches would be RTC. Development branches (the odd numbered
> ones) would be CTR.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message