Noel J. Bergman wrote:
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.
Yes, I didn't want to stop you from branching, as I said I'm +0 on that.
Btw I think that branching for a 2.3.0 release means that we agreed on a
roadmap for the release, but we didn't discuss this (recently).
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.
I agree!
In fact I always interpreted the "alpha" serie as milestones: milestones
or alphas are not stable releases.
I think we are simply using the same name for different things: that's
why I wrote this message ;-)
what you propose is not a branch for the alpha release, but a branch
for the whole 2.3.0 release.
Absolutely correct.
Ok.
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.
In your opinion what is the roadmap for 2.3.0 ? What kind of features
changes are allowed and what not? Can you write a short task list of
things you think we need before the 2.3.0 stable can be release (apart
bug fixing)?
I didn't think about this too much but there is at least one thing I
would not like to include in a final release and is the smtp
chainhandler stuff. I would like to hide it from the external until we
don't have a real modular solution. An example is the way I did it for
POP3 (simply hardcoded the default chain so the config.xml does not
declare the commands).
I need to think more about other things I don't like in the current
trunk to be in a final release, but I would like to hear the roadmap
from the other committers too.
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.
Ok ;-)
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.
We have different visions on this kind of changes.
I consider that patch a simple refactoring, nothing to call home about.
I just introduced an interface, renamed few methods, and separated the
code of one class in 2 classes. In fact most of the changes (80%) I did
on James in the last year are refactorings (I'm simply preparing the
sand for the features).
In fact it is probably more "significant" the lock/unlock/notify change
that involve only 4 lines, but maybe it introduce unexpected problems. I
did it because I consider the previous behaviour a bug and we can't know
if the new one work or not if we don't put it in the code ;-)
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.
Maybe you didn't understand the change I made, or maybe our idea of
"major change" is really different ;-)
Apart from moving code around I simply changed a "new Class()" with 8
lines of code to read an attribute with the classname and instantiate
the class by name.
Imho this is not a major change, and I think we should discuss more
about the parameter names that of the feature itself.
I agree with you that if you plan to release the ("2.3.0a2") v2.3 branch
as feature freezed this kind of changes should not be committed in
that branch, but I think that it is safe to apply similar refactorings
to a trunk even if we don't discuss it on the list (C-T-R).
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'm aware of all discussions made on the server-dev list in the last
year (year and half) and of the contents of the website and the wiki
pages, but I have not found much informations about who proposed what,
what is the agreements, and so on...
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.
I agree with that.
I only wanted to say again that I don't want to impose my changes or do
"my own james". I simply think this is the only way we can try to put
some innovations now, and I prefer to receive vetoes and revert code
than discuss about things for weeks.
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
That said, my main request is to know what is the roadmap for 2.3.0
final apart bugfixes.
Imho we should agree on that and understand what we expect from "2.3.0
final release".
I propose that everyone having issues with the 2.3.0a3 release features
should add a JIRA issue and that we may vote and comment the issues so
that we will have a clear roadmap to work in.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
