Bernd Fondermann wrote:
Bernd, this was by no means to be understood as an offense or anything
against other active contributors on this project. This List is neither
complete nor a concrete suggestion. Replace the Names in the Lists with
A, B, C, and D.
-1. Not agreed. I favor all the committers working together on the
current release. We don't want to split the community up. Other
projects here at Apache are in deep, deep trouble just because of
this!
I've proposed the "next-minor"/"next-major" because I don't see it as a
split. It is simply a group of people that put efforts to consolidate
some of the features we have in trunk, while new work in trunk is being
done.
So I don't think at this as a project fork, but simply a consolidation
branch, like we did for 2.3. The main difference between 2.3 is that
this time I already said I can't (and want) put my efforts on the
consolidation branch. Nothing terrible at all, nothing to call home for.
Imho the 2 active trees rule we agreed in past is still valid: trunk is
always the main active tree. We're waiting to close 2.3 so the
next-minor can be started and only when next-minor will be closed we're
going to open the next-major release.
Imho this make sense. We can't think we'll have the efforts of every
committer for everything we decide to do. There are many James
committers that did nothing since 2.1 but they still have the power to
vote (even if they don't do this so often). As you said everyone should
be able to do what he wants (by respecting the high-level project goals)
and when he wants (and not being managed) and we should only try to
synchronize/optimize our efforts.
Furthermore, I already wrote that the "split" could give our users the
best results (3 releases in 6 months!!) and let everyone work on the
preferred tree.
So do we/you want to deliver standards, or do you want to chase them?
Is that related to IMAP? Hopefully, this will be added soon.
Unfortunately I guess that IMAP won't be included in next-minor or
next-major, but we can only expect to be able to do some steps in that 2
releases (it would be *really* cool if we were able to put experimental
unstable support for imap in next-major but this is not realistic to me).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
