[IMAP][PROPOSAL] merge tags/seda-imap_M1 -> trunk

[robert burrell donkin <ro...@gmail.com>]

 the work i've been doing on the branch is pure refactoring: moving
around code that already exists. my aim is to factor the existing code
base so that it's possible to experiment with SEDA based strategies
including MINA without rewriting the protocol management logic. my
plan is to approach this in an incremental fashion. this has the
advantage that the code should be functional at all times. the
disadvantage is that it's not as clear how the changes achieve the
goal.

rather than waiting for a big bang merger, i'd prefer to move the
changes in incrementally a week or two behind the current branch. so,
i plan to cut a number of milestones so that developers can more
easily understand what's going on and review a reasonable quantity of
changes.

opinions?

i've been running
http://svn.apache.org/repos/asf/james/server/sandbox/tags/seda-imap_M1
for a week now. seems ok. i'd like to merge these changes in sometime
in the next couple of weeks. so if anyone who's interested could take
a look this week that'd be great.

- robert

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

Re: [IMAP][PROPOSAL] merge tags/seda-imap_M1 -> trunk

[robert burrell donkin <ro...@gmail.com>]

On 2/11/07, Stefano Bagnara <ap...@bago.org> wrote:
> robert burrell donkin ha scritto:
> > rather than waiting for a big bang merger, i'd prefer to move the
> > changes in incrementally a week or two behind the current branch. so,
> > i plan to cut a number of milestones so that developers can more
> > easily understand what's going on and review a reasonable quantity of
> > changes.
> >
> > opinions?
>
> +1
>
> Well, imho you could even use trunk as Joachim said he's not keen to
> work here for a while, so you won't overlap with anyone.
>
> Currently you are the only active committer, and you are working on a
> "never released" component, so there is no fear to break backward
> compatibity or something similar.
>
> If skipping the merge operaions helps your workflow and gives you more
> agility, I'm fine with it.

the milestone workflow suits me better (i test each milestone locally)

- robert

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

Re: [IMAP][PROPOSAL] merge tags/seda-imap_M1 -> trunk

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

robert burrell donkin ha scritto:
> rather than waiting for a big bang merger, i'd prefer to move the
> changes in incrementally a week or two behind the current branch. so,
> i plan to cut a number of milestones so that developers can more
> easily understand what's going on and review a reasonable quantity of
> changes.
> 
> opinions?

+1

Well, imho you could even use trunk as Joachim said he's not keen to 
work here for a while, so you won't overlap with anyone.

Currently you are the only active committer, and you are working on a 
"never released" component, so there is no fear to break backward 
compatibity or something similar.

If skipping the merge operaions helps your workflow and gives you more 
agility, I'm fine with it.

I personally check your changes at each commit, so I don't need the 
milstone tags. I only check the code but I don't run real tests on 
deployed IMAP.

Stefano


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

Re: [IMAP][PROPOSAL] merge tags/seda-imap_M1 -> trunk

[Bernd Fondermann <be...@googlemail.com>]

+1

On 2/11/07, robert burrell donkin <ro...@gmail.com> wrote:
>  the work i've been doing on the branch is pure refactoring: moving
> around code that already exists. my aim is to factor the existing code
> base so that it's possible to experiment with SEDA based strategies
> including MINA without rewriting the protocol management logic. my
> plan is to approach this in an incremental fashion. this has the
> advantage that the code should be functional at all times. the
> disadvantage is that it's not as clear how the changes achieve the
> goal.
>
> rather than waiting for a big bang merger, i'd prefer to move the
> changes in incrementally a week or two behind the current branch. so,
> i plan to cut a number of milestones so that developers can more
> easily understand what's going on and review a reasonable quantity of
> changes.
>
> opinions?
>
> i've been running
> http://svn.apache.org/repos/asf/james/server/sandbox/tags/seda-imap_M1
> for a week now. seems ok. i'd like to merge these changes in sometime
> in the next couple of weeks. so if anyone who's interested could take
> a look this week that'd be great.
>
> - robert
>
> ---------------------------------------------------------------------
> 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