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 Stefano Bagnara <ap...@bago.org> on 2006/11/20 19:54:13 UTC
[DISCUSSION] Preparing next-major
Hi all,
Norman and I made today an IM session to review current JIRA issue. We:
1. moved to "Trunk" every issue having an assignee and no fix version
2. moved to "Trunk" every issue assigned to "Next-Major" and that we
don't consider blocking for Trunk or we don't commit ourselves to fix soon.
3. created a list of issues we *could* work on before branching, but not
blocking for the branching purpose (see the bottom).
Please review the following issue list on JIRA:
Open issues for "Next-Major"
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&fixfor=10427&pid=10411&resolution=-1
Fix for "Trunk"
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&fixfor=12312135&pid=10411&resolution=-1
Undefined fix release
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&fixfor=-1&pid=10411&resolution=-1
If you think something else *must* be included in next-major or *should*
be included or you're likely to work on some backward compatible
(storage and config.xml) issue please speak now :-)
We propose Dec 15 as the next checkpoint: that day we'll verify every
"new feature"/"improvement"-issue assigned to next-major is fixed and
we'll start a vote for branching and to define the release number or to
delay the branch creation to a later date.
Once the branch will be created improvements/new features will be
allowed only in RTC while fixes in trunk/branch in CTR.
Stefano
And here is the list of issues we'll optionally work on:
-------
Stefano
JAMES-491 SpoolManager refactorings
JAMES-520 Create a RemoteDelivery service
JAMES-134 Large emails in the spool cause SpoolManager to throw
OutOfMemoryError
JAMES-241 fail gracefully upon large messages/attachments
JAMES-288 memory efficient retrieval
Norman
JAMES-552 Clamav code should be moved to a "generic" class to use it on
mailet,matcher,messagehandler
JAMES-670 Per IP connection limiting is not configurable per service,
nor is the configuration logged during initialization.
JAMES-599 BeanShell Scripting in James
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Preparing next-major
Posted by Bernd Fondermann <be...@googlemail.com>.
Hi,
My plan for next James release is to continue work on Management and
Monitoring and to use and test IMAP. Maybe I get some optimization
stuff done, too.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Preparing next-major
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
It seems to be a reasonable set of choices.
I will try to have james-616 in time for the next checkpoint.
Vincenzo
Stefano Bagnara wrote:
> Hi all,
>
> Norman and I made today an IM session to review current JIRA issue. We:
> 1. moved to "Trunk" every issue having an assignee and no fix version
> 2. moved to "Trunk" every issue assigned to "Next-Major" and that we
> don't consider blocking for Trunk or we don't commit ourselves to fix
> soon.
> 3. created a list of issues we *could* work on before branching, but
> not blocking for the branching purpose (see the bottom).
>
> Please review the following issue list on JIRA:
> Open issues for "Next-Major"
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&fixfor=10427&pid=10411&resolution=-1
>
> Fix for "Trunk"
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&fixfor=12312135&pid=10411&resolution=-1
>
> Undefined fix release
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&fixfor=-1&pid=10411&resolution=-1
>
>
> If you think something else *must* be included in next-major or
> *should* be included or you're likely to work on some backward
> compatible (storage and config.xml) issue please speak now :-)
>
> We propose Dec 15 as the next checkpoint: that day we'll verify every
> "new feature"/"improvement"-issue assigned to next-major is fixed and
> we'll start a vote for branching and to define the release number or
> to delay the branch creation to a later date.
>
> Once the branch will be created improvements/new features will be
> allowed only in RTC while fixes in trunk/branch in CTR.
>
> Stefano
>
>
> And here is the list of issues we'll optionally work on:
> -------
> Stefano
> JAMES-491 SpoolManager refactorings
> JAMES-520 Create a RemoteDelivery service
> JAMES-134 Large emails in the spool cause SpoolManager to throw
> OutOfMemoryError
> JAMES-241 fail gracefully upon large messages/attachments
> JAMES-288 memory efficient retrieval
>
> Norman
> JAMES-552 Clamav code should be moved to a "generic" class to use it
> on mailet,matcher,messagehandler
> JAMES-670 Per IP connection limiting is not configurable per service,
> nor is the configuration logged during initialization.
> JAMES-599 BeanShell Scripting in James
>
>
> ---------------------------------------------------------------------
> 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: [DISCUSSION] Preparing next-major
Posted by Bernd Fondermann <be...@googlemail.com>.
Hi Norman,
CTR would suggest yes.
+1, this stuff probably does what it says it does, so if you took care
of all others concerns (if any), please commit.
I have only my usual boring micro-complaints about coding style (for
example if(xx == false) => if (!xx)) which does not justify to hold
you back and am under the impression that user/account handling is in
bad need of general revision/refactoring which is beyond the scope of
this JIRA.
Bernd
On 11/29/06, Norman Maurer <nm...@byteaction.de> wrote:
> I whould also like to see my virtualHosting patch in next-major:
> http://issues.apache.org/jira/browse/JAMES-716
>
> But no comments yet .. Does this mean i should commit it ?
>
> bye
> Norman
>
>
> Vincenzo Gianferrari Pini schrieb:
> > It seems to be a reasonable set of choices.
> >
> > I will try to have james-616 in time for the next checkpoint.
> >
> > Vincenzo
> >
> > Stefano Bagnara wrote:
> >> Hi all,
> >>
> >> Norman and I made today an IM session to review current JIRA issue. We:
> >> 1. moved to "Trunk" every issue having an assignee and no fix version
> >> 2. moved to "Trunk" every issue assigned to "Next-Major" and that we
> >> don't consider blocking for Trunk or we don't commit ourselves to fix
> >> soon.
> >> 3. created a list of issues we *could* work on before branching, but
> >> not blocking for the branching purpose (see the bottom).
> >>
> >> Please review the following issue list on JIRA:
> >> Open issues for "Next-Major"
> >> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&fixfor=10427&pid=10411&resolution=-1
> >>
> >> Fix for "Trunk"
> >> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&fixfor=12312135&pid=10411&resolution=-1
> >>
> >> Undefined fix release
> >> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&fixfor=-1&pid=10411&resolution=-1
> >>
> >>
> >> If you think something else *must* be included in next-major or
> >> *should* be included or you're likely to work on some backward
> >> compatible (storage and config.xml) issue please speak now :-)
> >>
> >> We propose Dec 15 as the next checkpoint: that day we'll verify every
> >> "new feature"/"improvement"-issue assigned to next-major is fixed and
> >> we'll start a vote for branching and to define the release number or
> >> to delay the branch creation to a later date.
> >>
> >> Once the branch will be created improvements/new features will be
> >> allowed only in RTC while fixes in trunk/branch in CTR.
> >>
> >> Stefano
> >>
> >>
> >> And here is the list of issues we'll optionally work on:
> >> -------
> >> Stefano
> >> JAMES-491 SpoolManager refactorings
> >> JAMES-520 Create a RemoteDelivery service
> >> JAMES-134 Large emails in the spool cause SpoolManager to throw
> >> OutOfMemoryError
> >> JAMES-241 fail gracefully upon large messages/attachments
> >> JAMES-288 memory efficient retrieval
> >>
> >> Norman
> >> JAMES-552 Clamav code should be moved to a "generic" class to use it
> >> on mailet,matcher,messagehandler
> >> JAMES-670 Per IP connection limiting is not configurable per service,
> >> nor is the configuration logged during initialization.
> >> JAMES-599 BeanShell Scripting in James
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
> > !EXCUBATOR:1,456c6e3753072032517792!
>
>
>
> ---------------------------------------------------------------------
> 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: [DISCUSSION] Preparing next-major
Posted by Bernd Fondermann <be...@googlemail.com>.
On 11/29/06, Norman Maurer <nm...@byteaction.de> wrote:
> Hi Bernd,
>
> sure i took care of all concerns if i hadn't i whould upload it :-P
>
> About the coding style.. You know coding style differ from commiter to
> commiter. But if thats all you are not happy with then im happy .
If you don't agree with my suggestions and did the things I complain
about with a purpose, please keep your style.
In my own code I try to align my style with the already existing code,
so the code looks consistent.
>
> And yes user/account handling is really in need of great refactoring.
> But i asspect that its impossible to do this till we dedicite to drop a
> non-backward-compatible release.
Right.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Preparing next-major
Posted by Norman Maurer <nm...@byteaction.de>.
Hi Bernd,
sure i took care of all concerns if i hadn't i whould upload it :-P
About the coding style.. You know coding style differ from commiter to
commiter. But if thats all you are not happy with then im happy .
And yes user/account handling is really in need of great refactoring.
But i asspect that its impossible to do this till we dedicite to drop a
non-backward-compatible release.
bye
Norman
Bernd Fondermann schrieb:
> Hi Norman,
>
> CTR would suggest yes.
>
> +1, this stuff probably does what it says it does, so if you took care
> of all others concerns (if any), please commit.
>
> I have only my usual boring micro-complaints about coding style (for
> example if(xx == false) => if (!xx)) which does not justify to hold
> you back and am under the impression that user/account handling is in
> bad need of general revision/refactoring which is beyond the scope of
> this JIRA.
>
> Bernd
>
> On 11/29/06, Norman Maurer <nm...@byteaction.de> wrote:
>> I whould also like to see my virtualHosting patch in next-major:
>> http://issues.apache.org/jira/browse/JAMES-716
>>
>> But no comments yet .. Does this mean i should commit it ?
>>
>> bye
>> Norman
>>
>>
>> Vincenzo Gianferrari Pini schrieb:
>> > It seems to be a reasonable set of choices.
>> >
>> > I will try to have james-616 in time for the next checkpoint.
>> >
>> > Vincenzo
>> >
>> > Stefano Bagnara wrote:
>> >> Hi all,
>> >>
>> >> Norman and I made today an IM session to review current JIRA
>> issue. We:
>> >> 1. moved to "Trunk" every issue having an assignee and no fix version
>> >> 2. moved to "Trunk" every issue assigned to "Next-Major" and that we
>> >> don't consider blocking for Trunk or we don't commit ourselves to fix
>> >> soon.
>> >> 3. created a list of issues we *could* work on before branching, but
>> >> not blocking for the branching purpose (see the bottom).
>> >>
>> >> Please review the following issue list on JIRA:
>> >> Open issues for "Next-Major"
>> >>
>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&fixfor=10427&pid=10411&resolution=-1
>>
>> >>
>> >> Fix for "Trunk"
>> >>
>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&fixfor=12312135&pid=10411&resolution=-1
>>
>> >>
>> >> Undefined fix release
>> >>
>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&fixfor=-1&pid=10411&resolution=-1
>>
>> >>
>> >>
>> >> If you think something else *must* be included in next-major or
>> >> *should* be included or you're likely to work on some backward
>> >> compatible (storage and config.xml) issue please speak now :-)
>> >>
>> >> We propose Dec 15 as the next checkpoint: that day we'll verify every
>> >> "new feature"/"improvement"-issue assigned to next-major is fixed and
>> >> we'll start a vote for branching and to define the release number or
>> >> to delay the branch creation to a later date.
>> >>
>> >> Once the branch will be created improvements/new features will be
>> >> allowed only in RTC while fixes in trunk/branch in CTR.
>> >>
>> >> Stefano
>> >>
>> >>
>> >> And here is the list of issues we'll optionally work on:
>> >> -------
>> >> Stefano
>> >> JAMES-491 SpoolManager refactorings
>> >> JAMES-520 Create a RemoteDelivery service
>> >> JAMES-134 Large emails in the spool cause SpoolManager to throw
>> >> OutOfMemoryError
>> >> JAMES-241 fail gracefully upon large messages/attachments
>> >> JAMES-288 memory efficient retrieval
>> >>
>> >> Norman
>> >> JAMES-552 Clamav code should be moved to a "generic" class to use it
>> >> on mailet,matcher,messagehandler
>> >> JAMES-670 Per IP connection limiting is not configurable per service,
>> >> nor is the configuration logged during initialization.
>> >> JAMES-599 BeanShell Scripting in James
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
>> >
>> > !EXCUBATOR:1,456c6e3753072032517792!
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
> !EXCUBATOR:1,456d4f2253079747610589!
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Preparing next-major
Posted by Norman Maurer <nm...@byteaction.de>.
I whould also like to see my virtualHosting patch in next-major:
http://issues.apache.org/jira/browse/JAMES-716
But no comments yet .. Does this mean i should commit it ?
bye
Norman
Vincenzo Gianferrari Pini schrieb:
> It seems to be a reasonable set of choices.
>
> I will try to have james-616 in time for the next checkpoint.
>
> Vincenzo
>
> Stefano Bagnara wrote:
>> Hi all,
>>
>> Norman and I made today an IM session to review current JIRA issue. We:
>> 1. moved to "Trunk" every issue having an assignee and no fix version
>> 2. moved to "Trunk" every issue assigned to "Next-Major" and that we
>> don't consider blocking for Trunk or we don't commit ourselves to fix
>> soon.
>> 3. created a list of issues we *could* work on before branching, but
>> not blocking for the branching purpose (see the bottom).
>>
>> Please review the following issue list on JIRA:
>> Open issues for "Next-Major"
>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&fixfor=10427&pid=10411&resolution=-1
>>
>> Fix for "Trunk"
>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&fixfor=12312135&pid=10411&resolution=-1
>>
>> Undefined fix release
>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&fixfor=-1&pid=10411&resolution=-1
>>
>>
>> If you think something else *must* be included in next-major or
>> *should* be included or you're likely to work on some backward
>> compatible (storage and config.xml) issue please speak now :-)
>>
>> We propose Dec 15 as the next checkpoint: that day we'll verify every
>> "new feature"/"improvement"-issue assigned to next-major is fixed and
>> we'll start a vote for branching and to define the release number or
>> to delay the branch creation to a later date.
>>
>> Once the branch will be created improvements/new features will be
>> allowed only in RTC while fixes in trunk/branch in CTR.
>>
>> Stefano
>>
>>
>> And here is the list of issues we'll optionally work on:
>> -------
>> Stefano
>> JAMES-491 SpoolManager refactorings
>> JAMES-520 Create a RemoteDelivery service
>> JAMES-134 Large emails in the spool cause SpoolManager to throw
>> OutOfMemoryError
>> JAMES-241 fail gracefully upon large messages/attachments
>> JAMES-288 memory efficient retrieval
>>
>> Norman
>> JAMES-552 Clamav code should be moved to a "generic" class to use it
>> on mailet,matcher,messagehandler
>> JAMES-670 Per IP connection limiting is not configurable per service,
>> nor is the configuration logged during initialization.
>> JAMES-599 BeanShell Scripting in James
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
> !EXCUBATOR:1,456c6e3753072032517792!
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org