Am Samstag, den 13.05.2006, 19:09 +0200 schrieb Stefano Bagnara: > 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. >
If you hardcode the SMTPHandler stuff how to enable / disable some
features which are configured in the specific handler command ? Do you
want to move the configure to the "main" SMTPHandlerConfiguration ?
But i also agree that that the configure of the handlers in config.xml
is not the best solution cause so its easy to break stuff at all.
> >> 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 ;-)
>
I really understand why you want to do this.. i'm self working as
systemadmin and know its really frustrating to see that no new stable
release is published.
> >> 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.
That whould be the best solution. The roadmap should be clear before
publish the "final" 2.3 release
bye
Norman
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
