james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman ...@spam-box.de>
Subject Re: Roadmap again
Date Sat, 16 Dec 2006 12:33:16 GMT
Hi guys,

Joachim Draeger schrieb:
> Hi Bernd,
> Am Samstag, den 16.12.2006, 08:50 +0100 schrieb Bernd Fondermann:
>>> its now about 4 weeks ago when Stefano and me posted a roadmap proposal
>>> to the mailling list. Nothing concrete happen since this posting. I
>>> really whould like to get this odd roadmap stuff done now to focus on
>>> working on the next release. Without the roadmap it is impossible for me
>>> to help the project and work on concrete things.
>>> So what the stuff other people want to see in next release ? Is the
>>> proposed stuff ok ?
>> For the next release I would like to
>> + have basic (whatever than means) IMAP stable, perfoming and
>> functional, and well integrated with the rest of James architecture.
> That would introduce probably some incompatibility. I'm fine with this
> if there is a majority.
> I always try to let the new stuff run beside the old one without
> changing anything. I work this way only because I see it as problematic
> in this project to introduce big changes. 
>> + have more online management and monitoring features done
> Yes, that is very important and will broaden significantly the target
> group. 
> Be transparent and less cryptic.


>> + have a Spring distribution besides the other packages
> Let's do it! :-)

If im not wrong then there is allready a sandbox on which joachim is workin.

>>> I whould also like to focus on a branch date. Maybe branch in 2/2007  ?
>> I would rather not call for a "branch date", but focus on "feature
>> freeze" and "release" dates.
>> Branching is just a technical thing which can be completely omitted if
>> we release from trunk.
> There seemed to be a consensus that the next release should be
> config/storage compatible. This compatibility limits the introducing of
> new features.
> If we want to have a compatible release we IMO need the branch to be
> able to work on non compatible features in trunk while stabilizing the
> branch.
> You seem to favor a non-compatible release. (So do I and some others
> that saw the compatible one as a compromise)  
> In this case I agree with you that we should continue working in trunk
> and decide later whether a branch is needed or not. 
I agree with you..  But if we want to break compatibility we should do
it carefully so no further compatibilily changes have to be done in near

> Well, as the last approach has been beaten down that unkind, (which
> still makes me very sad) we need possibly a new vote for a direction.
> James often makes the impression to me to be headless and indecisive.
> That makes me feel unsure and uncomfortable if this is the right place
> for my open source work. Too much energy gets wasted. For me this is
> some kind of a last chance before I will draw the conclusions.
> I appeal to the James community and to the PMC to make again all
> assiduous efforts to come out of this mess. Something has to change
> right now.
I agree. We have to change something... The first things we have to do
now is:

* Define if the next release should be compatible or not
* Define a clear roadmap
* Define a version number ( not so importent for me , but it seems its
importent for others)
* Define feature freeze date/ branch date / release date

After that i hope we all can focus and work on concrete stuff.
>> And I would like to have us release from trunk, because it keeps us
>> focused on testing and finalizing.
>> Would a release target date end of Q2/Y07 be OK?
> This is one of the options I can agree on. Because it's quite a long
> period we could maybe introduce milestones. We are all voluntaries, no
> one will force us to meet deadlines. 
> But clear targets are important for humans. So yes, define a release
> date, and maybe dates for alpha and beta releases. We are free to change
> them whenever we think it's reasonable.

> Joachim


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

View raw message