Stefano,
> I'd like to hear opinions of all committers before starting the branch
Well, I've already made the branch, but we can discuss it, and remove it if
necessary, but I will strongly argue for the branch.
> branch would means also that there will be effort to mantain that branch.
YES, there IS an effort to create both a stable release and continue radical
development of the codebase. You cannot aggressively destablize key
portions of the code, and also prepare for a release unless you separate the
stable from the unstable.
> what you propose is not a branch for the alpha release, but a branch
> for the whole 2.3.0 release.
Absolutely correct.
> This would mean the branch is feature freezed.
This is not correct. We can add features, but we will be CAREFUL as to
which changes go into the branch.
> I consider the current trunk nothing more than a milestone.
And I want to get a stable RELEASE out the door! And I am trying to set it
up so that we can do that without stopping other development.
> Your "we don't really have a choice" is your opinion or is something
> related to some apache/james rule I don't know?
I refer to the changes regarding spool manangement and processors, which
were not been discussed -- not even hinted at that I recall --, are
significant changes, effect the core, and should not be made if we are
serious about trying to SHIP a RELEASE anytime soon.
> About the prior proposal/discussion I want to make clear that every
> commit I do is subject to review.
I understand that, but when making major changes, you might actually want to
let people know what is planned. Did you know that we had already discussed
similar changes, e.g., <processor class="...">? So the concept is fine, and
what you did might be fine. But not for this release. Hence the need to
separate the two.
> Often it takes much less to do things than to discuss them, so I simply
> choose this way (en example is the JamesSpoolManager refactoring: I
> would have lost hours trying to explain the idea, it took much less and
> it is more clear to commit the change).
Or you might have found out about prior proposals, and we could have
discussed the various options and come to a consensus.
> I would not mind to revert refactorings or new features commit
I'm not vetoing your changes nor asking for them to be reverted. I just
want to separate stable code from destablized code, and prepare for the
release.
> My main priority (where I will spend most of my efforts) is
> cleaning/refactorings that allow more modularity
All fine, but not at the expense of getting the release done.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
