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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
