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: Roadmap? Or maybe not... [WAS Re: [VOTE] next-major from trunk will be 3.0]
Date Wed, 01 Aug 2007 15:38:26 GMT
Bernd Fondermann ha scritto:
> Stefano Bagnara wrote:
>>> On 8/1/07, Robert Burrell Donkin <robertburrelldonkin@gmail.com> wrote:
>>>> this is a classic case of evolution verses revolution
>>>> you wanted a revolution but ended up evolving the existing code base.
>>>> architecture by stealth typically creates community issues and so is
>>>> best avoided.
>> Bernd Fondermann wrote:
>>> +1
>>> Thanks, Robert. Great post!
>> Bernd, can you just tell me if the +1 was also specific to the sentence
>> above? (as a specific reference to what I did in the last 2 years in
>> JAMES Server).
> No it wasn't.
> I think Robert's analysis to be correct and unbiased. I now believe to
> understand what went wrong and why and how it can be avoided.
> I don't read the sentence you picked up as personal criticism of anyone.

the sentence started with "you": either I am a single part of the plural
you, or I am the singular you ;-)
Maybe "architecture by stealth" is not something negative as I read it,
but I'm happy anyway to have asked this and to have received this answer
(google didn't help me with the definition).

> Generally speaking, looking into the past is only useful when learning
> for the future.

I agree. That's why I'm still talking about this topics even if I don't
have concrete plans on JAMES anymore. I want to be sure I understood
what happened and what is the opinions of others about what happened
(expecially related to my mistakes).

And anyway, I wouldn't be offended by Robert criticisms, as he was not
here, so can only guess what happened. I, sometimes, feel disappointed
by words spoken by people that was here and saw what happened.

> The modularisation in fact opens the possibility for everyone to be
> represented here in source code - the conservative, the evolutionary and
> even the revolutionary - the fast and the slow - the pro-compatibility
> and the con-compatibility.
> It's a technical trick to unsnare - to allow for people with different
> goals to participate (or to not participate, in the sense of not to
> block progress). It works for the moment, at least.
>   Bernd

My personal opinion is that it is working really good at the moment, but
mainly because there is no concurrency and there is no ongoing
refactoring on old code. Excluding the spring module you are porting and
IMAP (both things where not part of 2.3.x) we had no single bug
fixed/feature added in the last 8 months in existing modules of trunk:
many of the refactorings we did in trunk before the modularizations
would have required changes in all of the modules anyway.

I will agree that the modularization is the solution to our problems
when I will start seeing the core to be evolved at the same rhythm we
did it in past. In the mean time I can only enjoy the better structure,
but I can't perceive this big panacea you all see, yet.

Btw I think we already have much simpler tasks to be solved first, like
removing the User from the imap-api module so to not have core-library
to depend on imap-api, then we can see how other refactorings will
impact on this multi module layout.

Maybe the next rainy weekend I will revamp my old fetchmail proposal and
propose to put there as an experimental-fetchmail, now that we have such
modularization: this way it won't get lost forever in the JIRA attachment.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message