james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: 2.3.0a3 release plans
Date Sat, 13 May 2006 17:09:09 GMT
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message