larryi 01/01/23 12:45:20
Modified: . RELEASE-PLAN-3.3 STATUS.html
Log:
Another round of changes, including a spellcheck pass.
I may be done, assuming I haven't missed something important.
Revision Changes Path
1.5 +17 -16 jakarta-tomcat/RELEASE-PLAN-3.3
Index: RELEASE-PLAN-3.3
===================================================================
RCS file: /home/cvs/jakarta-tomcat/RELEASE-PLAN-3.3,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- RELEASE-PLAN-3.3 2001/01/22 21:21:44 1.4
+++ RELEASE-PLAN-3.3 2001/01/23 20:45:07 1.5
@@ -18,10 +18,11 @@
Changes:
Tomcat 3.3 will implement no new major features compared with 3.2.
- Some tunning and improvements are made to various modules to increase
- the usability and flexibility. The "changes3.3" document includes the
- code changes done during tomcat development. ( XXX needs to be
- cleaned and reorganized in STATUS )
+ Some tuning and improvements are made to various modules to increase
+ the usability and flexibility. The STATUS.HTML document summarizes
+ some of these changes in the action items marked for the 3.3 release.
+ The "changes3.3" document provides a more detailed list of the
+ code changes.
Most of the changes are related with continuing the refactoring of the
3.x and performance enhancements that couldn't make it into 3.2.
@@ -43,8 +44,8 @@
discussed and incorporated. Also, the documentation will be reviewed
and improved.
- In parallel, work will start on fixing a significant number ( most ? ) of
- bugs that were reported and fixed in 3.2 and post 3.2. This work will
+ In parallel, work will start on fixing all bugs and making other changes
+ as required by the Release criteria given below. This work will
continue during the beta period.
Whenever possible, we should try to create a self-test case ( using
@@ -96,7 +97,7 @@
Release Manager: Larry Isaacs
The final build. The pre-requisite for the release is having no bugs in
- the test suite, resolution for all known bugs and aproval by the community.
+ the test suite, resolution for all known bugs and approval by the community.
Release criteria
@@ -107,7 +108,7 @@
1. Tomcat 3.3 should have no regression compared with 3.2.
Any reported regression is a show-stopper and a release can't be made
-before it is resovled.
+before it is resolved.
2. Open bugs should be resolved.
@@ -122,7 +123,7 @@
6. Full review of the code, making sure the modularity and extensibility
goals have been achieved.
-7. Make sure that the refactoring is clean, and maintainance will be
+7. Make sure that the refactoring is clean, and maintenance will be
easier that 3.2
8. Ensure that the performance is (significantly) better than
@@ -134,9 +135,9 @@
-Platorms.
+Platforms.
We must make sure that tomcat test reports ( at least watchdog + self-test )
-contributed by developers and usrs exists for at least Linux, Solaris,
+contributed by developers and users exists for at least Linux, Solaris,
Windows 9x, Windows NT/2000. It is desirable to have test reports on
MacOS 9/X, FreeBSD.
@@ -150,7 +151,7 @@
( possibly ) with IIS and NES ( low priority ).
-Maintainance Plan
+Maintenance Plan
=================
The release team must consist of at least 3 people, and will fix any major
@@ -158,16 +159,16 @@
minor releases, if absolutely needed ( security or stability bugs ).
In any case, no backward-incompatible or major changes should be made.
-The release team must coordinate the maintainace and support of tomcat,
+The release team must coordinate the maintenance and support of tomcat,
dispatching bugs and user requests to developers and acting as the
last resort in resolving major support issues.
Release Team
============
-The release team will be composed from the commiters that give the binding
+The release team will be composed of the committers that give the binding
+1 on the release plan and release proposal. It must have at least 3
-memebers, and follow the rules that will be established.
+members, and follow the rules that will be established.
The release team will coordinate the execution of the release plan, dispatch
bugs to volunteers, review commits, and act as a lead in the release
@@ -176,4 +177,4 @@
One of the team members will act as "Release Manager" and will be
responsible for building the milestones, making the announcements about
the release progress and all other roles that will be set by PMC and
-commiters.
+committers.
1.9 +17 -18 jakarta-tomcat/STATUS.html
Index: STATUS.html
===================================================================
RCS file: /home/cvs/jakarta-tomcat/STATUS.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- STATUS.html 2001/01/22 21:21:44 1.8
+++ STATUS.html 2001/01/23 20:45:09 1.9
@@ -5,7 +5,7 @@
<body bgcolor="white">
<div align="center">
-NOTE: This document is the first cut at a status document<br>
+NOTE: This document is the current cut at a status document<br>
to track outstanding issues for the ongoing development of<br>
Tomcat. Nothing in this document should be considered<br>
authoritative until it has been discussed and initially<br>
@@ -126,11 +126,10 @@
<tr>
<td>High</td>
<td>3.3</td>
- <td>Refactoring of existing code to improve configurability and flexibility
- of Tomcat, as well as minimize the amount of spaghetti code to help
- readability and maintainability of the code. Though listed separately,
- some of the performance improvements come about as part of this
- refactoring effort.</td>
+ <td>Refactoring of existing code to improve the flexibility of Tomcat
+ and minimize the amount of spaghetti code to help readability and
+ maintainability. Though listed separately, some of the performance
+ improvements come about as part of this refactoring effort.</td>
<td><a href="mailto:[EMAIL PROTECTED]">Costin Manolache</a></td>
</tr>
<tr>
@@ -518,7 +517,7 @@
<tr>
<td>High</td>
<td>3.3</td>
- <td>Simplify running of Tomcat's internal test and Watchdog to encourge
+ <td>Simplify running of Tomcat's internal test and Watchdog to encourage
wider use of these tests. If possible, create a user document describing
how a user can develop a new test to test their own web application. If
user created tests are simple enough, we will get better verification that
@@ -549,33 +548,33 @@
<tr>
<td>High</td>
<td>3.3</td>
- <td>Code review and improve code documentation</td>
- <td>Code review voluteers</td>
+ <td>Code review and improve code documentation. All unfinished implementation
+ that can be identified, often marked with "XXX" in a comment, needs to
+ be examined to determine if its completion is required by the release
+ standard.</td>
+ <td>Code review volunteers</td>
</tr>
<tr>
<td>High</td>
<td>3.3</td>
- <td>Add and improve user documentation.</td>
+ <td>Add and improve user documentation. Documentation in both binary and
+ source distribution needs to be addressed.</td>
<td>Documentation volunteers</td>
</tr>
<tr>
<td>High</td>
<td>3.3</td>
+ <td>Security holes opened to facilitate development and testing need to be
+ closed prior to final release. Any additional security holes that are
+ identified need to be addressed.</td>
<td>---</td>
- <td>---</td>
- </tr>
- <tr>
- <td>High</td>
- <td>3.3</td>
- <td>---</td>
- <td>---</td>
</tr>
</table>
<br>
<div align="center"><hr width="75%"><font size="2">
-$Id: STATUS.html,v 1.8 2001/01/22 21:21:44 larryi Exp $
+$Id: STATUS.html,v 1.9 2001/01/23 20:45:09 larryi Exp $
</font></div>
</body>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
