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 "Peter M. Goldstein" <pe...@yahoo.com> on 2002/09/26 21:45:57 UTC
Release Plan
My first copy of this email didn't seem to go through, so I'm
resending...
This is a proposed release plan for the 2.1 release.
The primary goal of this plan is to get a stable, scalable, and
functional James 2.1 out in October, and allow the developers as a group
to move on to a discussion of future releases.
Relevant Dates:
Feature Freeze: 10/3/02
Code Freeze: 10/11/02
Doc Freeze: 10/11/02
Branch Date: 10/12/02
Formal Test Period: 10/12/02 - 10/20/02
Release Date: 10/21/02
Definition of Terms:
Feature Freeze - After this date the only changes to source code are to
resolve bugs. No new features or system enhancements will be made
between this date and the release date
Code Freeze - After this date, submission of any code requires a formal
vote. This ensures maximum code stability. By this date, all features
intended to be included in the release should be committed and tested.
All bugfixes for bugs known before the feature freeze date should be in
the code base should similarly be committed and tested. Only bugs
discovered after feature freeze should be considered for resolution
after this point.
Doc Freeze - After this date, there should be no changes to
documentation. All intended documentation fixes should be committed.
Branch Date - The 2.1 base will be branched at this point, to provide
the ability to address bugfixes in the 2.1 release without impeding the
developers' ability to work on the next version.
Formal Test Period: In this time frame participants on the james-dev
list will test the application in a variety of environments to the best
of their ability. The app can also be made available as a beta, and
given to james-user for testing.
Release Date: This is the date where the package is distributed. This
will be accompanied by a formal release notice on the web site. The
notice will either incorporate or link to an informal change list for
modifications since the last official version.
Incomplete Features/Issues to be Incorporated in this Version:
1) Write up specific documentation addressing the top 5 issues listed on
the TODO list.
2) Change code so that it doesn't use the TimeScheduler in the assorted
server blocks (excluding the newly introduced FetchPOP)
3) Include Andrei's changes to address connection handler
performance/robustness issues.
4) Bugs #2288, #4003, #6928, #8861, #9669, #11640, #12031, #12120.
5) Add documentation for the use of FetchPOP
6) Confirm TLS Support for POP3 - This is really a rather simple piece
of functionality. Move status from experimental to stable.
Thoughts? Feedback?
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Release Plan
Posted by "Noel J. Bergman" <no...@devtech.com>.
Danny,
If you think back, you'll recollect this discussion.
Using TimeScheduler for FetchPOP makes perfect sense: you are scheduling
fetch operations. TimeScheduler as a socket watchdog in the handlers is a
disaster. Far too fine grained. Major hit on object creation (with
attendant memory and performance issues).
--- Noel
-----Original Message-----
From: Danny Angus [mailto:danny@apache.org]
Sent: Thursday, September 26, 2002 17:27
To: James Developers List
Subject: RE: Release Plan
> 2) Change code so that it doesn't use the TimeScheduler in the assorted
> server blocks (excluding the newly introduced FetchPOP)
Sorry, slightly off the topic of this thread, whats wrong with
TimeScheduler, and why is it OK for fetchpop, have I missed something?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Release Plan
Posted by Danny Angus <da...@apache.org>.
I thought so, but couldn't remember it being discussed, my tunnel vision no
doubt.
> -----Original Message-----
> From: Peter M. Goldstein [mailto:peter_m_goldstein@yahoo.com]
> Sent: 26 September 2002 22:32
> To: 'James Developers List'
> Subject: RE: Release Plan
>
>
>
> Danny,
>
> > > 2) Change code so that it doesn't use the TimeScheduler in the
> assorted
> > > server blocks (excluding the newly introduced FetchPOP)
> >
> > Sorry, slightly off the topic of this thread, whats wrong with
> > TimeScheduler, and why is it OK for fetchpop, have I missed something?
>
> TimeScheduler is not designed to be used as it is being used by the
> assorted Handlers. In each of the Handlers, it's being used as a
> centralized generic timeout tool. This has led to observed memory,
> robustness, and throughput problems (see archives for details) largely
> because of the massive number of short lived tasks being managed by the
> TimeScheduler. As FetchPOP uses it as it was intended to be used - as a
> tool to execute tasks at scheduled intervals - there's no problem there.
>
> --Peter
>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Release Plan
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Danny,
> > 2) Change code so that it doesn't use the TimeScheduler in the
assorted
> > server blocks (excluding the newly introduced FetchPOP)
>
> Sorry, slightly off the topic of this thread, whats wrong with
> TimeScheduler, and why is it OK for fetchpop, have I missed something?
TimeScheduler is not designed to be used as it is being used by the
assorted Handlers. In each of the Handlers, it's being used as a
centralized generic timeout tool. This has led to observed memory,
robustness, and throughput problems (see archives for details) largely
because of the massive number of short lived tasks being managed by the
TimeScheduler. As FetchPOP uses it as it was intended to be used - as a
tool to execute tasks at scheduled intervals - there's no problem there.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Release Plan
Posted by Danny Angus <da...@apache.org>.
> 2) Change code so that it doesn't use the TimeScheduler in the assorted
> server blocks (excluding the newly introduced FetchPOP)
Sorry, slightly off the topic of this thread, whats wrong with
TimeScheduler, and why is it OK for fetchpop, have I missed something?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>