On 9/21/07, Jim Jagielski <[EMAIL PROTECTED]> 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
