You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Danny Angus <da...@apache.org> on 2008/01/21 15:50:52 UTC
[PLANNING] Road map - lets find some consensus on .... release contents ....
Hi,
Roadmap ... we need to do this to give ourselves some direction.
The two questions are "what" we should release and "when" we should release it.
I just want to focus on "what" first, we'll look at "when" once we know what.
We have two targets, an incremental release of the current live
version, which we will call "next minor" and the next major release
from James trunk which we will call "next major"
So...
What do *you* want to include in each of these targets?
And ... remember that we have had problems with these discussions
before, so please lets all think before we speak. I don't mind if we
argue over important differences of opinion, but lets listen carefully
and try not to argue when we actually agree :-)
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PLANNING] Road map - lets find some consensus on .... release contents ....
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Jan 22, 2008 9:29 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> >>> mime4j - completion of refactoring
> >> I'm not sure how much energy this will take and how we should delay a
> >> release, but why don't we release 0.4 based on the current codebase and
> >> then refactor more in 0.5 ?
> >> We did this with jSPF and we made a lot of releases. I think it is
> >> better to have many incompatible releases than no releases ;-)
> >> Having a release means that users will download and test it, and will
> >> report bugs against a specific codebase.
> >> I think we solved most of legal issues related to the release of mime4j.
> >
> > IIRC mime4j is only required for mailbox etc
>
> Looking at the poms it is only imported by
> experimental-activemq-function and searching the java files I can only
> find SimpleMailBuilder inside that module.
i have an uncommitted patch that fixes some IMAP bugs which relies on
mime4j. also, once jsieve is released, mime4j will be required by the
sieve mailet which again is dependent on mailbox.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PLANNING] Road map - lets find some consensus on .... release
contents ....
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
>>> mime4j - completion of refactoring
>> I'm not sure how much energy this will take and how we should delay a
>> release, but why don't we release 0.4 based on the current codebase and
>> then refactor more in 0.5 ?
>> We did this with jSPF and we made a lot of releases. I think it is
>> better to have many incompatible releases than no releases ;-)
>> Having a release means that users will download and test it, and will
>> report bugs against a specific codebase.
>> I think we solved most of legal issues related to the release of mime4j.
>
> IIRC mime4j is only required for mailbox etc
Looking at the poms it is only imported by
experimental-activemq-function and searching the java files I can only
find SimpleMailBuilder inside that module.
BTW, even if I agree this is offtopic if not required in the Server
roadmap, I think anyway we could also plan a mime4j release, too.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PLANNING] Road map - lets find some consensus on .... release contents ....
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Jan 22, 2008 9:09 PM, Stefano Bagnara <ap...@bago.org> wrote:
<snip>
> jSieve: do we just need to package a release, review and vote on it (I
> don't see open JIRA issues for 0.2)? I think we already discussed the
> possibility to release it on 24/10/2007 and everyone agreed we were
> ready. I can't sign releases, but I can support with any other related
> task (review, run tests, update JIRA and website for the release, add
> the news, etc).
it's ready to release given someone stepping up to act as release manager
> > mime4j - completion of refactoring
>
> I'm not sure how much energy this will take and how we should delay a
> release, but why don't we release 0.4 based on the current codebase and
> then refactor more in 0.5 ?
> We did this with jSPF and we made a lot of releases. I think it is
> better to have many incompatible releases than no releases ;-)
> Having a release means that users will download and test it, and will
> report bugs against a specific codebase.
> I think we solved most of legal issues related to the release of mime4j.
IIRC mime4j is only required for mailbox etc
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PLANNING] Road map - lets find some consensus on .... release contents ....
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Jan 22, 2008 9:09 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On Jan 22, 2008 6:39 PM, Stefano Bagnara <ap...@bago.org> wrote:
<snip>
> >>>>> 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.
> >
> > (moving code around into modules really isn't a substantive issue and
> > is easy to reverse)
>
> I will rephrase it as: I don't get why backporting to a v2.3 branch
> should be easier than choosing a bunch of modules from trunk.
> Or, alternatively, I can ask a question: What, in current trunk modules
> (exluding *imap* and *mailbox*) should not be backported?
core plus potentially any module depending on core ;-)
this really means tacking the modularisation more seriously and adding
a more sophisticated component system
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PLANNING] Road map - lets find some consensus on .... release contents ....
Posted by Danny Angus <da...@apache.org>.
> ATM JAMES allows developers to create third party plugins but does not
> clearly indicate which APIs are subject to change
+1 API's need to be an early target.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PLANNING] Road map - lets find some consensus on .... release contents ....
Posted by Danny Angus <da...@apache.org>.
On Jan 24, 2008 10:51 AM, Stefano Bagnara <ap...@bago.org> wrote:
> I just wanted to say that *all* of our upgrading users have a config.xml
> and stored mails to take care upgrading, while a minority have custom
> components (I would bet less than 10%, but this is just my personal guess).
>
> That's why I think config.xml and storage compatibility should be a
> greater priority compared to API stability.
I agree an upgrade path is a necessity, but it could also include a
transform script to migrate files to a new format.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PLANNING] Road map - lets find some consensus on .... release contents ....
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Jan 28, 2008 2:37 PM, Stefano Bagnara <ap...@bago.org> wrote:
>
> Robert Burrell Donkin ha scritto:
> > On Jan 26, 2008 4:48 PM, Stefano Bagnara <ap...@bago.org> wrote:
> >> Robert Burrell Donkin ha scritto:
> >>> On Jan 24, 2008 10:51 AM, Stefano Bagnara <ap...@bago.org> wrote:
> >>>> That's why I think config.xml and storage compatibility should be a
> >>>> greater priority compared to API stability.
> >>> JAMES needs more active developers. releasing unstable APIs damages
> >>> the development ecology.
> >> It's clear we have different opinions on this.
> >>
> >> IMHO most JAMES developers are JAMES users that knows JAVA and in a
> >> given point in time decide they want to start writing some Mailets, and
> >> then move writing some service and then start hacking the core, and
> >> become more involved in the developers community.
> >
> > exactly :-)
> >
> > mailet authors should be able to rely on a stable set of basic
> > exterior service APIs. breaking into finely grained components is
> > great but it creates a lot of interior interfaces to allow
> > implementations to be extended. it isn't clear which APIs are intended
> > for mailet and protocol developers, and which are interior APIs aimed
> > at extenders of a particular backend implementation.
> >
> > - robert
>
> AFAIK only Mailet API are intended for mailet developers, now.
>
> And we never exposed "public" protocol APIs.
that's the point: developer wanting to independently extend JAMES are
faced with moving targets and the JAMES team are faced with worries
about breaking API compatibility
> Only SIMPLE mailets can be written using public APIs. Everything else,
> is JAMES Server core hacking (access the ServiceManager via a context
> lookup and know what is declared in the assembly).
>
> Long before I joined this project I know that JAMES PMC evaluated the
> possibility to put repositories knowledge in the mailet apis and some
> more service, but I think it never landed the official code. I don't
> know why.
>
> IMHO internal apis can be made public only when we used it for a while
> and we are satisfied with them to say that we won't change them for a
> while. This is not the case of current and past internal interfaces.
they are already public :-)
we're just not doing a good job of telling independent developers
which APIs will be preserved between versions and which may change
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PLANNING] Road map - lets find some consensus on .... release
contents ....
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Jan 26, 2008 4:48 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Jan 24, 2008 10:51 AM, Stefano Bagnara <ap...@bago.org> wrote:
>>>> That's why I think config.xml and storage compatibility should be a
>>>> greater priority compared to API stability.
>>> JAMES needs more active developers. releasing unstable APIs damages
>>> the development ecology.
>> It's clear we have different opinions on this.
>>
>> IMHO most JAMES developers are JAMES users that knows JAVA and in a
>> given point in time decide they want to start writing some Mailets, and
>> then move writing some service and then start hacking the core, and
>> become more involved in the developers community.
>
> exactly :-)
>
> mailet authors should be able to rely on a stable set of basic
> exterior service APIs. breaking into finely grained components is
> great but it creates a lot of interior interfaces to allow
> implementations to be extended. it isn't clear which APIs are intended
> for mailet and protocol developers, and which are interior APIs aimed
> at extenders of a particular backend implementation.
>
> - robert
AFAIK only Mailet API are intended for mailet developers, now.
And we never exposed "public" protocol APIs.
Only SIMPLE mailets can be written using public APIs. Everything else,
is JAMES Server core hacking (access the ServiceManager via a context
lookup and know what is declared in the assembly).
Long before I joined this project I know that JAMES PMC evaluated the
possibility to put repositories knowledge in the mailet apis and some
more service, but I think it never landed the official code. I don't
know why.
IMHO internal apis can be made public only when we used it for a while
and we are satisfied with them to say that we won't change them for a
while. This is not the case of current and past internal interfaces.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PLANNING] Road map - lets find some consensus on .... release contents ....
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Jan 26, 2008 4:48 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On Jan 24, 2008 10:51 AM, Stefano Bagnara <ap...@bago.org> wrote:
> >> That's why I think config.xml and storage compatibility should be a
> >> greater priority compared to API stability.
> >
> > JAMES needs more active developers. releasing unstable APIs damages
> > the development ecology.
>
> It's clear we have different opinions on this.
>
> IMHO most JAMES developers are JAMES users that knows JAVA and in a
> given point in time decide they want to start writing some Mailets, and
> then move writing some service and then start hacking the core, and
> become more involved in the developers community.
exactly :-)
mailet authors should be able to rely on a stable set of basic
exterior service APIs. breaking into finely grained components is
great but it creates a lot of interior interfaces to allow
implementations to be extended. it isn't clear which APIs are intended
for mailet and protocol developers, and which are interior APIs aimed
at extenders of a particular backend implementation.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PLANNING] Road map - lets find some consensus on .... release
contents ....
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Jan 24, 2008 10:51 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> That's why I think config.xml and storage compatibility should be a
>> greater priority compared to API stability.
>
> JAMES needs more active developers. releasing unstable APIs damages
> the development ecology.
It's clear we have different opinions on this.
IMHO most JAMES developers are JAMES users that knows JAVA and in a
given point in time decide they want to start writing some Mailets, and
then move writing some service and then start hacking the core, and
become more involved in the developers community.
Everything starts from the users community: I keep in mind that JAMES is
an OLD project and has already many users.
My 2 cents,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PLANNING] Road map - lets find some consensus on .... release contents ....
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Jan 24, 2008 10:51 AM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On Jan 22, 2008 9:09 PM, Stefano Bagnara <ap...@bago.org> wrote:
> >> IMHO stability of the API between components is a lesser priority
> >> compared to the config.xml+storage compatibility for an early release.
> >> The former is something targeting developers, the latter is something
> >> targeting every user.
> >
> > users are effected when an upgrade breaks a custom component
> >
> > ATM JAMES allows developers to create third party plugins but does not
> > clearly indicate which APIs are subject to change
>
> I just wanted to say that *all* of our upgrading users have a config.xml
> and stored mails to take care upgrading, while a minority have custom
> components (I would bet less than 10%, but this is just my personal guess).
>
> That's why I think config.xml and storage compatibility should be a
> greater priority compared to API stability.
JAMES needs more active developers. releasing unstable APIs damages
the development ecology.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PLANNING] Road map - lets find some consensus on .... release
contents ....
Posted by Norman Maurer <no...@apache.org>.
Am Donnerstag, den 24.01.2008, 11:51 +0100 schrieb Stefano Bagnara:
> d stored mails to take care upgrading, while a minority have custom
> components (I would bet less than 10%, but this is just my personal
> guess).
>
> That's why I think config.xml and storage compatibility should be a
> greater priority compared to API stability.
>
+1
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PLANNING] Road map - lets find some consensus on .... release
contents ....
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Jan 22, 2008 9:09 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> IMHO stability of the API between components is a lesser priority
>> compared to the config.xml+storage compatibility for an early release.
>> The former is something targeting developers, the latter is something
>> targeting every user.
>
> users are effected when an upgrade breaks a custom component
>
> ATM JAMES allows developers to create third party plugins but does not
> clearly indicate which APIs are subject to change
I just wanted to say that *all* of our upgrading users have a config.xml
and stored mails to take care upgrading, while a minority have custom
components (I would bet less than 10%, but this is just my personal guess).
That's why I think config.xml and storage compatibility should be a
greater priority compared to API stability.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PLANNING] Road map - lets find some consensus on .... release contents ....
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Jan 22, 2008 9:09 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On Jan 22, 2008 6:39 PM, Stefano Bagnara <ap...@bago.org> wrote:
> >> 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.
> >
> > (it's not just IMAP but also the backend that IMAP depends on that isn't ready)
>
> I agree, but IIRC 99% of that code is not used by the "legacy" JAMES
> Server. The backend for IMAP has been written for IMAP. POP3, SMTP,
> NNTP, RemoteManager still depends on the same old components. We simply
> refactored a lot of service interfaces (API) used between this components.
>
> IMHO stability of the API between components is a lesser priority
> compared to the config.xml+storage compatibility for an early release.
> The former is something targeting developers, the latter is something
> targeting every user.
users are effected when an upgrade breaks a custom component
ATM JAMES allows developers to create third party plugins but does not
clearly indicate which APIs are subject to change
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PLANNING] Road map - lets find some consensus on .... release
contents ....
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Jan 22, 2008 6:39 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> 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.
>
> (it's not just IMAP but also the backend that IMAP depends on that isn't ready)
I agree, but IIRC 99% of that code is not used by the "legacy" JAMES
Server. The backend for IMAP has been written for IMAP. POP3, SMTP,
NNTP, RemoteManager still depends on the same old components. We simply
refactored a lot of service interfaces (API) used between this components.
IMHO stability of the API between components is a lesser priority
compared to the config.xml+storage compatibility for an early release.
The former is something targeting developers, the latter is something
targeting every user.
>>>>> 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.
>
> (moving code around into modules really isn't a substantive issue and
> is easy to reverse)
I will rephrase it as: I don't get why backporting to a v2.3 branch
should be easier than choosing a bunch of modules from trunk.
Or, alternatively, I can ask a question: What, in current trunk modules
(exluding *imap* and *mailbox*) should not be backported?
> (whether it's called 2.5 or 3.0) the APIs are the main issue - we
> really need to take a good look at the way that JAMES is composed
I think a release with the features that are waiting since an year is
MUCH more important than discussing JAMES composition. Integers for
version numbers are infinite, so a good plan would be to release
something (as we have something to release) and then improve things in
the following release. BTW I had no success with such a plan when I was
proposing to put my forces in working on it, I don't expect to see this
happen now that I'm no more active on this (but hope is the last to die
:-) ).
>>>>> 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?
>
> the current backend APIs touched by IMAP are not satisfactory:
> releasing them will just create yet another fork without IMAP. we'll
> end up in exactly the same situation
>
> until someone steps up to sort out the APIs, milestones are the best approach
I agreed and agree that milestone is the best way.
Once users will test the milestone we'll collect experiences and we'll
be able to decide how to proceed.
>>>>> 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?
>
> mailbox manager and implementations are the major areas. this couples
> over to some some other functions such as jsieve integration.
Again we have in trunk 3 things:
A remodularized and slightly improved v2.3 codebase + spring deployment
+ a lot of new code for IMAP and its backed. They are 3 totally separate
and different things.
> it's the APIs that are important: IMO the API dependencies really need
> to be understood and sorted out
Most users don't care about APIs but instead they care of features. Of
course it is good to be able to target also developers and to have
better API. IMHO a better API is not a good cause to delay a release for
1 year. Yes, most new features are there since more than 1 year and IMHO
there is no good explanation for this when we reply to some server-user
questions.
>> - SMTP Server
>> - 8bitmime support [beta]
>> - Greylisting support [alpha/norman?]
>> - SPF support [beta]
>> - Better SpamAssassin support [beta]
>> - Support for POP-before-SMTP (roaming users) [norman?]
>> - URI blacklist support [norman?]
>> - URIRBLHandler for fastfail [norman?]
>> - Add reverse lookup checks and HELO/EHLO checks in SMTP [norman?]
>> - Support Connection Limit per IP [beta]
>
> which of these improvements are in the protocol and which are mailets?
Everything in protocol.
>> - 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]
>
> how is virtual hosting coupled to the protocols?
Most of virtual hosting support has been achieved by altering service
interfaces and contracts between components. Protocols interact with the
service interfaces. Many core interfaces/components have been changed
(sometimes slightly) to add this features, but I think this resulted in
a better separation of concerns between core services.
>> Well, this seems a plan. What is blocking mailet/jsieve/mime4j releases?
>
> mailet, jsieve - energy
About mailet: do we want to delay the next major release of JAMES Server
until we'll have defined the next generation mailet API or do we want to
cut a earlier JAMES Server release against the latest released mailet API?
jSieve: do we just need to package a release, review and vote on it (I
don't see open JIRA issues for 0.2)? I think we already discussed the
possibility to release it on 24/10/2007 and everyone agreed we were
ready. I can't sign releases, but I can support with any other related
task (review, run tests, update JIRA and website for the release, add
the news, etc).
> mime4j - completion of refactoring
I'm not sure how much energy this will take and how we should delay a
release, but why don't we release 0.4 based on the current codebase and
then refactor more in 0.5 ?
We did this with jSPF and we made a lot of releases. I think it is
better to have many incompatible releases than no releases ;-)
Having a release means that users will download and test it, and will
report bugs against a specific codebase.
I think we solved most of legal issues related to the release of mime4j.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PLANNING] Road map - lets find some consensus on .... release contents ....
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Jan 22, 2008 6:39 PM, Stefano Bagnara <ap...@bago.org> wrote:
> 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.
(it's not just IMAP but also the backend that IMAP depends on that isn't ready)
> >>> 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.
(moving code around into modules really isn't a substantive issue and
is easy to reverse)
(whether it's called 2.5 or 3.0) the APIs are the main issue - we
really need to take a good look at the way that JAMES is composed
> >>> 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?
the current backend APIs touched by IMAP are not satisfactory:
releasing them will just create yet another fork without IMAP. we'll
end up in exactly the same situation
until someone steps up to sort out the APIs, milestones are the best approach
> >>> 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?
mailbox manager and implementations are the major areas. this couples
over to some some other functions such as jsieve integration.
it's the APIs that are important: IMO the API dependencies really need
to be understood and sorted out
> > 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?]
> - SPF support [beta]
> - Better SpamAssassin support [beta]
> - Support for POP-before-SMTP (roaming users) [norman?]
> - URI blacklist support [norman?]
> - URIRBLHandler for fastfail [norman?]
> - Add reverse lookup checks and HELO/EHLO checks in SMTP [norman?]
> - Support Connection Limit per IP [beta]
which of these improvements are in the protocol and which are mailets?
> - 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]
how is virtual hosting coupled to the protocols?
> - 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?
mailet, jsieve - energy
mime4j - completion of refactoring
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PLANNING] Road map - lets find some consensus on .... release
contents ....
Posted by Norman Maurer <no...@apache.org>.
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
Re: [PLANNING] Road map - lets find some consensus on .... release
contents ....
Posted by Stefano Bagnara <ap...@bago.org>.
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.
>>> 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?
>>> 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?]
- SPF support [beta]
- Better SpamAssassin support [beta]
- Support for POP-before-SMTP (roaming users) [norman?]
- URI blacklist support [norman?]
- URIRBLHandler for fastfail [norman?]
- Add reverse lookup checks and HELO/EHLO checks in SMTP [norman?]
- 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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PLANNING] Road map - lets find some consensus on .... release contents ....
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Jan 21, 2008 11:49 PM, Danny Angus <da...@apache.org> wrote:
> So we're looking for a plan to sort out trunk, with realistic milestones then?
sorting out trunk would take a lot of energy but may not be necessary
if we branch then prune
(i have some more comments related to this but i'll add them to the
module thread)
> The first milestone should be 3.0.0M1 an alpha branch of selected
> trunk changes for review, but never realistically destined to be the
> stable 3.0.0?
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
> To be followed by successive milestone releases until we have a
> radically new James architecture. for 3.0.0 Yes/No?
sounds good to me
> On Jan 21, 2008 11:10 PM, Stefano Bagnara <ap...@bago.org> wrote:
> > Danny Angus ha scritto:
> > > Hi,
> > > Roadmap ... we need to do this to give ourselves some direction.
> > >
> > > The two questions are "what" we should release and "when" we should release it.
> > >
> > > I just want to focus on "what" first, we'll look at "when" once we know what.
> > >
> > > We have two targets, an incremental release of the current live
> > > version, which we will call "next minor" and the next major release
> > > from James trunk which we will call "next major"
> >
> > Welcome back to the labels ;-)
> >
> > > So...
> > >
> > > What do *you* want to include in each of these targets?
> >
> > 2.3.2: we have no outstanding bugs on 2.3.1, so I don't think we have to
> > plan a 2.3.2 right now.
> >
> > 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 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
>> 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)
i think that it would be useful to compose a list.
which new features:
* ready for full release?
* beta?
* alpha?
> > 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
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PLANNING] Road map - lets find some consensus on .... release contents ....
Posted by Danny Angus <da...@apache.org>.
So we're looking for a plan to sort out trunk, with realistic milestones then?
The first milestone should be 3.0.0M1 an alpha branch of selected
trunk changes for review, but never realistically destined to be the
stable 3.0.0?
To be followed by successive milestone releases until we have a
radically new James architecture. for 3.0.0 Yes/No?
d.
On Jan 21, 2008 11:10 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Danny Angus ha scritto:
> > Hi,
> > Roadmap ... we need to do this to give ourselves some direction.
> >
> > The two questions are "what" we should release and "when" we should release it.
> >
> > I just want to focus on "what" first, we'll look at "when" once we know what.
> >
> > We have two targets, an incremental release of the current live
> > version, which we will call "next minor" and the next major release
> > from James trunk which we will call "next major"
>
> Welcome back to the labels ;-)
>
> > So...
> >
> > What do *you* want to include in each of these targets?
>
> 2.3.2: we have no outstanding bugs on 2.3.1, so I don't think we have to
> plan a 2.3.2 right now.
>
> 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.
>
> 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) 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.
>
> 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).
>
> Stefano
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PLANNING] Road map - lets find some consensus on .... release
contents ....
Posted by Stefano Bagnara <ap...@bago.org>.
Danny Angus ha scritto:
> Hi,
> Roadmap ... we need to do this to give ourselves some direction.
>
> The two questions are "what" we should release and "when" we should release it.
>
> I just want to focus on "what" first, we'll look at "when" once we know what.
>
> We have two targets, an incremental release of the current live
> version, which we will call "next minor" and the next major release
> from James trunk which we will call "next major"
Welcome back to the labels ;-)
> So...
>
> What do *you* want to include in each of these targets?
2.3.2: we have no outstanding bugs on 2.3.1, so I don't think we have to
plan a 2.3.2 right now.
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.
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) 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.
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).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org