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. Costin On 9/21/07, Jim Jagielski <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
