What's In 3.0? [WAS Re: [VOTE] next-major from trunk will be 3.0]

[Robert Burrell Donkin <ro...@gmail.com>]

On 8/3/07, Stefano Bagnara <ap...@bago.org> wrote:
> Danny Angus ha scritto:
> > On 8/3/07, Stefano Bagnara <ap...@bago.org> wrote:
> >
> >> I also agree that it added confusion: I had a clear view on what
> >> next-minor and next-major was and at that time I thought it was clear to
> >> everyone (I'm used to labels to identify software sprints). But the
> >> facts proved my believing was wrong.
> >
> > I think that was the problem, not that it was a bad idea, but that we
> > didn't all have the same understanding. We use labels in this way at
> > work too, to great effect, somehow it just didn't catch on here.
>
> FWIW, even now that we have 3.0 instead of next-major, I don't have an
> understanding of people preferences/ideas about the future of JAMES. Not
> that my understanding is important now, but I hope someone will better
> collect such moods/opinions.

+1

> It "seems" we now agree we need a 3.0M1, this would be already a great
> step: I really hope to see a 3.0M1 out there, soon!
>
> My opinion is unchanged since next-major: imho we can have a release
> even tomorrow, maybe we should consider whether it is better to release
> another version of the handlerapi (the current trunk) or it is better to
> release 3.0M1 using the 2.3.1 handlerapi, or it is better to release one
> of the experimental handlerapi.
>
> I'm not a fan of the current handlerapi as I think it introduce
> incompatibilities with the experimental 2.3.x support and it does not
> provide a sufficient platform for the future (so I expect to see further
> changes there sooner or later), but for the major goal of a release I'd
> sacrifice almost anything, so I'm fine with any code will be there.

the milestone is technology preview. if there's some dispute about the
best implementations of parts of the code then let's port them in as
modules into trunk (we can argue about whether their labels later).
then all we need to decide is which should ship as default.

feedback from users should be very useful in deciding the best approach

the handlerapi isn't really my area so someone else would need to
volunteer push this forward

- robert

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

Re: What's In 3.0? [WAS Re: [VOTE] next-major from trunk will be 3.0]

[Norman Maurer <no...@apache.org>]

Stefano Bagnara schrieb:
> Robert Burrell Donkin ha scritto:
>   
>> On 8/3/07, Stefano Bagnara <ap...@bago.org> wrote:
>>     
>>> My opinion is unchanged since next-major: imho we can have a release
>>> even tomorrow, maybe we should consider whether it is better to release
>>> another version of the handlerapi (the current trunk) or it is better to
>>> release 3.0M1 using the 2.3.1 handlerapi, or it is better to release one
>>> of the experimental handlerapi.
>>>
>>> I'm not a fan of the current handlerapi as I think it introduce
>>> incompatibilities with the experimental 2.3.x support and it does not
>>> provide a sufficient platform for the future (so I expect to see further
>>> changes there sooner or later), but for the major goal of a release I'd
>>> sacrifice almost anything, so I'm fine with any code will be there.
>>>       
>> the milestone is technology preview. if there's some dispute about the
>> best implementations of parts of the code then let's port them in as
>> modules into trunk (we can argue about whether their labels later).
>> then all we need to decide is which should ship as default.
>>     
>
> I agree.
>
>   
>> feedback from users should be very useful in deciding the best approach
>>     
>
> Will we be able to support our users on every implementation we have in
> trunk? I personally have limited knowledge in some handlerapi code and
> with the imap modules.
> IMHO we should at least care to release as default something that we are
> ready to support and for which someone will reply to user questions.
>
>   
>> the handlerapi isn't really my area so someone else would need to
>> volunteer push this forward
>>     
>
>
> I have knowledge of the experimental handlerapi code we release in
> 2.3.x. The we had 2 branches, one sandbox and trunk evolving with
> different solutions.
>
> I know what's in the handlerapi-experiment sandbox and I can tell it is
> a big refactoring involving changes in the core and in most modules so
> to refactoring of the current code to support a SEDA pattern, so maybe
> we should ignore it for 3.0M1.
>
> I don't know much of the trunk vs 2.3 and the 2 branches: maybe Noel or
> Norman can help us identifying what's what and what do they think we
> should include in M1.
>   

I whould stick with the version from 2.3.x. The new design in trunk is 
to "incomplete". But i think the best code is still in the handlerapi 
project Stefano and me put in the sandbox.



> What I would like to avoid is releasing one more different experimental
> handlerapi with the knowledge we will change it again in M2 and then
> again in M3 and so on. In this case I would prefer to revamp 2.3 code
> for handlerapi and keep that module as "default" for a while (while we
> better understand what can be done there).
>
> Stefano
>   

+1
Norman



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

Re: What's In 3.0? [WAS Re: [VOTE] next-major from trunk will be 3.0]

[Robert Burrell Donkin <ro...@gmail.com>]

On 8/7/07, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:

<snip>

> > feedback from users should be very useful in deciding the best approach
>
> Will we be able to support our users on every implementation we have in
> trunk? I personally have limited knowledge in some handlerapi code and
> with the imap modules.
> IMHO we should at least care to release as default something that we are
> ready to support and for which someone will reply to user questions.

a milestone is just a preview. we're not committed to support anything.

> > the handlerapi isn't really my area so someone else would need to
> > volunteer push this forward
>
>
> I have knowledge of the experimental handlerapi code we release in
> 2.3.x. The we had 2 branches, one sandbox and trunk evolving with
> different solutions.
>
> I know what's in the handlerapi-experiment sandbox and I can tell it is
> a big refactoring involving changes in the core and in most modules so
> to refactoring of the current code to support a SEDA pattern, so maybe
> we should ignore it for 3.0M1.
>
> I don't know much of the trunk vs 2.3 and the 2 branches: maybe Noel or
> Norman can help us identifying what's what and what do they think we
> should include in M1.
>
> What I would like to avoid is releasing one more different experimental
> handlerapi with the knowledge we will change it again in M2 and then
> again in M3 and so on. In this case I would prefer to revamp 2.3 code
> for handlerapi and keep that module as "default" for a while (while we
> better understand what can be done there).

sounds ok to me but i'm not really up on the handlerapi code

opinions?

- robert

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

Re: What's In 3.0? [WAS Re: [VOTE] next-major from trunk will be 3.0]

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> On 8/3/07, Stefano Bagnara <ap...@bago.org> wrote:
>> My opinion is unchanged since next-major: imho we can have a release
>> even tomorrow, maybe we should consider whether it is better to release
>> another version of the handlerapi (the current trunk) or it is better to
>> release 3.0M1 using the 2.3.1 handlerapi, or it is better to release one
>> of the experimental handlerapi.
>>
>> I'm not a fan of the current handlerapi as I think it introduce
>> incompatibilities with the experimental 2.3.x support and it does not
>> provide a sufficient platform for the future (so I expect to see further
>> changes there sooner or later), but for the major goal of a release I'd
>> sacrifice almost anything, so I'm fine with any code will be there.
> 
> the milestone is technology preview. if there's some dispute about the
> best implementations of parts of the code then let's port them in as
> modules into trunk (we can argue about whether their labels later).
> then all we need to decide is which should ship as default.

I agree.

> feedback from users should be very useful in deciding the best approach

Will we be able to support our users on every implementation we have in
trunk? I personally have limited knowledge in some handlerapi code and
with the imap modules.
IMHO we should at least care to release as default something that we are
ready to support and for which someone will reply to user questions.

> the handlerapi isn't really my area so someone else would need to
> volunteer push this forward


I have knowledge of the experimental handlerapi code we release in
2.3.x. The we had 2 branches, one sandbox and trunk evolving with
different solutions.

I know what's in the handlerapi-experiment sandbox and I can tell it is
a big refactoring involving changes in the core and in most modules so
to refactoring of the current code to support a SEDA pattern, so maybe
we should ignore it for 3.0M1.

I don't know much of the trunk vs 2.3 and the 2 branches: maybe Noel or
Norman can help us identifying what's what and what do they think we
should include in M1.

What I would like to avoid is releasing one more different experimental
handlerapi with the knowledge we will change it again in M2 and then
again in M3 and so on. In this case I would prefer to revamp 2.3 code
for handlerapi and keep that module as "default" for a while (while we
better understand what can be done there).

Stefano


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