james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer <nor...@apache.org>
Subject Re: [PLANNING] Road map - lets find some consensus on .... release contents ....
Date Tue, 22 Jan 2008 20:25:22 GMT
Hi all,

sorry im quite busy at the moment with some migrations.. So I will try
to respond to all mails later.. Some comments are inline..


Am Dienstag, den 22.01.2008, 19:39 +0100 schrieb Stefano Bagnara:
> Robert Burrell Donkin ha scritto:
> > it's a milestone rather than an alpha. we don't have alpha quality
> > code that we intend to fix up and release but a mixed bag which we
> > cannot promise will be compatible with an eventual 3.0 release
> 
> I agree. And if we don't plan to include IMAP then probably "2.5" would 
> be a better name, for what will not be compatible with 3.0, but can lead 
> to an intermediate release.

+1

> 
> >>> next-minor (2.4 ?): this is Noel field. My opinion is unchanged. IMHO we
> >>> should work on trunk because backporting to the old structure IMHO is
> >>> too much work and does not make sense. BTW if anyone is willing to work
> >>> on this, well, why not: the more we release the better.
> > 
> > depends on the feature: i was wondering about backporting components
> > rather than source. i suspect that this should be much easier.
> 
> I'm not sure I understand the "backporting components".
> 
> v2.3 branch is not "modularized" like trunk and there are many changes 
> at the api level between v2.3 and trunk, because we tried to fix up some 
> service interface to better modularize the components.
> 
> Noel made some reference to very limited features to be "backported": 
> per IP connection limit, the old dns cache issue.
> I would like to understand what else and how would be included in a 
> similar backport. As an example, the way Noel proposed to fix the dns 
> issue in next-minor is not a backport from trunk, because the dnsserver 
> in trunk has a lot of fixes more and we changed a lot that service and 
> the way other components interact with it (moving from static uses of 
> the component to service injections).
> 
> >>> I think a better plan is to try to release at least one milestone from
> >>> trunk and depending on the feedback we'll have on the milestones we'll
> >>> be able to decide whether it's better to make more milestones from trunk
> >>> or it is better to branch for consolidation.
> >>>
> >>> I don't speak about IMAP (I think Robert will tell us what he thinks
> >>> about IMAP modules and their status)
> > 
> > IMAP is better but isn't ready
> 
> What about a release including IMAP only as an experimental/alpha 
> module, but having the remaining server as a 2.3 backward compatible 
> server with some improvements?

+1

> 
> >>> but I think most of the other
> >>> modules in trunk are ready (since 13 months) for a milestone/alpha/beta
> >>> release and they already provide a lot of new features compared to
> >>> 2.3.1. Most of the code in trunk should be storage and config.xml
> >>> compatible with 2.3.1.
> > 
> > i'm not sure how true is (there are a number of features touched by
> > IMAP which aren't ready)
> 
> What features? The mailboxmanager is only used by IMAP. I don't think 
> there is much core code that has been changed to accomodate IMAP 
> modules. Had I forgotten anything?
> 
> > i think that it would be useful to compose a list.
> > 
> > which new features:
> > 
> >  * ready for full release?
> >  * beta?
> >  * alpha?
> 
> Most code have to be tested more (and that's why we need a release), but 
> I think most of it can be considered beta as we already know some user 
> is running trunk code.
> 
>  From an old email dated 17/07/2007 (Spring Deployment) here is a list 
> of features in trunk:
> Sure, FYI here is a list of new features already in trunk. I added the 
> alpha/beta status or the name of who may tell us what's the status:
> 
> - SMTP Server
>    - 8bitmime support [beta]
>    - Greylisting support [alpha/norman?]

 -> beta

>    - SPF support [beta]
>    - Better SpamAssassin support [beta]
>    - Support for POP-before-SMTP (roaming users) [norman?]
 -> beta
>    - URI blacklist support [norman?]
 -> alpha
>    - URIRBLHandler for fastfail [norman?]
 -> alpha
>    - Add reverse lookup checks and HELO/EHLO checks in SMTP [norman?]
-> beta
>    - Support Connection Limit per IP [beta]
> 
> - Virtual hosting / Dynamic reloading / JMX+RemoteManager management
>    - introduced the VirtualUserTable (VUT) Service [beta]
>    - Support dynamic reload of servernames [beta]
>    - Added JMX+RM operations for spool/mail repositories and user 
> management. [bernd?]
>    - Support the use of VUT to extract servernames. [beta]
>    - Added management for the new VUT store/repository. [alpha/beta]
>    - Added management interfaces and remotemanager commands to manage the
> servername list [alpha/beta]
> 
> - Critical Issues
>    - Almost fully rewritten DNSServer to fix OOM issues and some critical
> caching bug. [beta]
>    - Added search-domain configurability to DNSServer [beta]
>    - Introduced Commons Daemon to run james as non root. [beta]
> 
> >>> Unfortunately now I cannot be active as I was 13 months ago when I
> >>> proposed to cut a milestone from that code, but this is anyway my
> >>> opinion on the code we have.
> >>>
> >>> Most of our "SNAPSHOT" dependencies have been upgraded to finals in the
> >>> past year, now we only have mailet, jsieve and mime4j as snapshot
> >>> dependencies. Maybe we should try to cut releases for that products
> >>> before trying with Server (but this is not mandatory).
> > 
> > yes, this is the first step
> 
> Well, this seems a plan. What is blocking mailet/jsieve/mime4j releases?
> 
> Stefano
> 
> 

bye
Norman



---------------------------------------------------------------------
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