tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <cos...@gmail.com>
Subject Re: Review model take 2
Date Fri, 21 Sep 2007 17:23:54 GMT
On 9/21/07, Jim Jagielski <jim@jagunet.com> wrote:
>
>
> On Sep 21, 2007, at 11:12 AM, Costin Manolache wrote:
>
> > 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
> > problem,
> > 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
> > changes
> > 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.
> >
>
> But anything that *reaches* a release branch is ALWAYS RTC. So,
> by design and definition, anything that affects other people,
> does so because it is part of a release branch and therefore,
> since it is part of the release branch, got in there via RTC.



I'm a bit confused - what happens with the trunk then ? Usually the
trunk will become the new release - or the code from the trunk will somehow
get released.

But forget the release/trunk details - the question is how to determine the
goals or direction - things like should use switch coyote to nio, should we
change the API in one way or another, how much backward compatibility to
preserve, what to deprecate and what to bundle by default. Doesn't matter
where
it happens - the reason we have this conversation is because this kind of
decision was made by one or 2 people fighting each other and without
enough consensus - instead of the broader community.

Both Remy and Filip ( and quite a few other people actually ) are quick to
express their disapproval for something or their goals - and maybe sometimes
too blunt
and personal.

The proposed processes ( with their evident flaws ) are intended
to make it clear that neither of us 'decides' ( by veto or by sumitting
something ) -
either we have a consensus ( everyone agrees ), or at least the typical 3
+1  and
majority.

Costin

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