On 9/21/07, Jim Jagielski <[EMAIL PROTECTED]> wrote: > > > On Sep 21, 2007, at 1:23 PM, Costin Manolache wrote: > > There are 2 ways for code in trunk to get released: > > 1. trunk, the whole kit and kaboodle becomes a release > branch. For this to happen, RTC comes in and the > PMC and dev community agree that trunk should serve > as the basis for TC X.Y.
Ok, but what is the decision process about what goes into the trunk, in case changes lack consensus ? Let's assume CTR ( lazy consensus - i.e. assume everyone agrees ) - what if it turns that the consensus is lacking, not on the technical validity of the change but on weather a particular change is the right direction. Should tomcat bundle the CGI / SSI support - or have a smaller set of feature in the base, like jetty ? NIO or apr ? Keep backward compat or fix major problems - and what's the middle line ? Current process seems to be 'everyone throws whatever in the trunk - as long as nobody can find a valid technicality for a veto, at the end the community takes the whole things and agrees/disagrees'. I.e. what we had so far, leading to lots of frustration on both sides. And if 2 people have different opinion on an API in the trunck - first to make the change that can't be vetoed, or gives up in the flame war - wins. API and big, long term changes and the direction of the project shouldn't be lazy consensus, no matter if done in trunk or branch, i.e. result of one individual submitting (valid) code. It needs some more comunity involvment. Costin
