cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
larryi 01/09/17 19:44:45 Modified:.RELEASE-PLAN-3.3 Log: Update to current status. Moved Bug 1798 to RC2 just to provide a little more time to verify that we can't duplicate it. Revision ChangesPath 1.14 +24 -19jakarta-tomcat/RELEASE-PLAN-3.3 Index: RELEASE-PLAN-3.3 === RCS file: /home/cvs/jakarta-tomcat/RELEASE-PLAN-3.3,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- RELEASE-PLAN-3.3 2001/09/13 19:57:38 1.13 +++ RELEASE-PLAN-3.3 2001/09/18 02:44:45 1.14 @@ -164,16 +164,22 @@ "realSession.setAttribute()", the second request's value would be overwritten without an valueUnbound() being called. +RESOLUTION: Implemented + 2. Evaluate Tomcat 3.3's vulnerability to "Double Checked Locking". This is referred to in Bug #177. See: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html for details. I think ServletHandler.init() is currently subject to this vulnerability. +RESOLUTION: Implemented + 3. The spec doesn't address whether a the form-login-page and form-error-page should be excluded from the security-constraint, but it makes sense that it should. It might be best to postpone this. +RESOLUTION: Postponed. + 4. Address user authentication via Ajp12 and Ajp13. Ajp12 has a test for isTomcatAuthentication() to see if req.setRemoteUser() should be called. I think Ajp13 doesn't have this yet and probably should. Also, if the @@ -181,33 +187,32 @@ with this value? This prevents Tomcat's normal authentication from being triggered. +RESOLUTION: tomcatAuthentication property has been added to Ajp13. + 5. If a error handler is not found for an exception, check the root cause as well if it is a ServletException. This is mentioned in Bug 3233. I think it would be a good idea to apply this. I don't think we are prohibited by the spec. We could add an option to be safe if there is concern. +RESOLUTION: Implemented. + 6. StaticInterceptor is missing a localization enhancement added to Tomcat 3.2.x. Should this enhancement be ported to Tomcat 3.3? Is this still considered a regression, though it isn't part of the Servlet 2.2/JSP 1.1 spec? +RESOLUTION: Postponed to RC2 + 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. +RESOLUTION: Minimized vulnerability. + + Must Resolve Bugs: -177 Race condition during servlet initialization BugRat Report#2 -182 JSP error-page doesn't work with virtual hosts BugRat Report -274 request.getUserPrincipal() doesn't work when user is authent -437 req.getParameter(name) Ignores charset. always assumes ISO88 -463 Ctx( /examples ): IOException in: R( /examples + + null) No 1253 Frequent Connection reset by peer errors -1663 Tomcat -SSL problem -1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after -3233 exception handling wrt errorpages seems to be incorrect -3486 Session problem (with case insensitive context matching on windows) -3572 HttpSessionFacade.invalidate don't unbound Attributes -3577 NPE when DecodeInterceptor gets confused + Tomcat 3.3 Release Candidate 2: @@ -238,6 +243,8 @@ to include some justification in the documentation to avoid some of the "why don't you" questions. +IN PROGRESS: Making user configurable + 12. To simplify upgrade development, I would like to see the classpath for the "container", "common", and "apps" classloaders include the directory so classes placed under them will be picked up. @@ -245,18 +252,14 @@ 13. Determine cause of pauses running Tomcat's internal test with Tomcat + IIS. +14. StaticInterceptor is missing a localization enhancement added to +Tomcat 3.2.x. Should this enhancement be ported to Tomcat 3.3? + Must Resolve Bugs: -82Jasper not affected by mod_rewrite BugRat Report#49 (part of issue 11) -111 after httpd reload mod_jk fails to find a worker BugRat Repo -276 JNI problem: bufferedreader.read fails in Tomcat/IIS/JNI set -319 Nor Hig All [EMAIL PROTECTED] UNCO Tomcat does not launch with given - Unix script files BugRat R -405 response.sendRedirect() in MS Explorer 5.5 fails using both -620 StopTomcat defaults to localhost +1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after 2333 HTTP Reason will be destroyed in header using AJP12 2550 Ajp13 Connection hanging on static content. -2927 ArrayIndexOutOfBoundsException when accessing ajp13 3581 Ctx() : Error creating validation mark - java.io.FileNotFoundException Tomcat 3.3 Final Release @@ -271,7 +274,9 @@ Open in 3.2.x But Fixed in 3
Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
At least with isTomcatAuth="false" and mod_ssl configured properly, 274 should work now. I don't have a system configured to be able to test it (e.g. no user certs), but mod_ssl will set REMOTE_USER to the CN, and Ajp13 will allocate a SimplePrincipal to match the REMOTE_USER. - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, September 13, 2001 12:57 PM Subject: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3 > larryi 01/09/13 12:57:38 > > Modified:.RELEASE-PLAN-3.3 > Log: > Update to the release plan. Also: > > Bugs 3572 and 3577 have been added as required for RC1 > > Bug 3581 has been added as required for RC2 > > Bug 1482 has been moved to the "fixed in 3.3" catagory > > Revision ChangesPath > 1.13 +122 -5jakarta-tomcat/RELEASE-PLAN-3.3 > > Index: RELEASE-PLAN-3.3 > === > RCS file: /home/cvs/jakarta-tomcat/RELEASE-PLAN-3.3,v > retrieving revision 1.12 > retrieving revision 1.13 > diff -u -r1.12 -r1.13 > --- RELEASE-PLAN-3.3 2001/06/21 04:42:08 1.12 > +++ RELEASE-PLAN-3.3 2001/09/13 19:57:38 1.13 > @@ -147,16 +147,133 @@ > 1. TBD... > > > +Tomcat 3.3 Release Candidate 1: > + > + Code Freeze/Tag Date: Sept 14, 2001 > + Release Manager: Larry Isaacs > + > + This release should be used to verify that we really are > + at release quality. It should include any fixes needed > + to reach that status. Documentation updates may continue > + after this release. > + > +To Be Addressed for RC1: > + > +1. HttpSessionFacade.setAttribute() isn't synchronized. If a second request > +called "setAttribute()" after this request's "removeAttribute()" and before > +"realSession.setAttribute()", the second request's value would be overwritten > +without an valueUnbound() being called. > + > +2. Evaluate Tomcat 3.3's vulnerability to "Double Checked Locking". This > +is referred to in Bug #177. See: > +http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html > +for details. I think ServletHandler.init() is currently subject to this > +vulnerability. > + > +3. The spec doesn't address whether a the form-login-page and form-error-page > +should be excluded from the security-constraint, but it makes sense that > +it should. It might be best to postpone this. > + > +4. Address user authentication via Ajp12 and Ajp13. Ajp12 has a test for > +isTomcatAuthentication() to see if req.setRemoteUser() should be called. > +I think Ajp13 doesn't have this yet and probably should. Also, if the > +user is anonymous, i.e. user = "", should we call req.setRemoteUser() > +with this value? This prevents Tomcat's normal authentication from being > +triggered. > + > +5. If a error handler is not found for an exception, check the root cause > +as well if it is a ServletException. This is mentioned in Bug 3233. I think > +it would be a good idea to apply this. I don't think we are prohibited > +by the spec. We could add an option to be safe if there is concern. > + > +6. StaticInterceptor is missing a localization enhancement added to > +Tomcat 3.2.x. Should this enhancement be ported to Tomcat 3.3? Is > +this still considered a regression, though it isn't part of the > +Servlet 2.2/JSP 1.1 spec? > + > +7. Evaluate whether anything should be done to deal with the use of > +non-thread-safe DateFormat and related classes. > + > +Must Resolve Bugs: > + > +177 Race condition during servlet initialization BugRat Report#2 > +182 JSP error-page doesn't work with virtual hosts BugRat Report > +274 request.getUserPrincipal() doesn't work when user is authent > +437 req.getParameter(name) Ignores charset. always assumes ISO88 > +463 Ctx( /examples ): IOException in: R( /examples + + null) No > +1253 Frequent Connection reset by peer errors > +1663 Tomcat -SSL problem > +1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after > +3233 exception handling wrt errorpages seems to be incorrect > +3486 Session problem (with case insensitive context matching on windows) > +3572 HttpSessionFacade.invalidate don't unbound Attributes > +3577 NPE when DecodeInterceptor gets confused > + > +Tomcat 3.3 Release Candidate 2: > + > + Code Freeze/Tag Date: Sept 21, 2001 > + Release Manager: Larry Isaacs > + > + Will be the build put to a vote as a release. This
cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
larryi 01/09/13 12:57:38 Modified:.RELEASE-PLAN-3.3 Log: Update to the release plan. Also: Bugs 3572 and 3577 have been added as required for RC1 Bug 3581 has been added as required for RC2 Bug 1482 has been moved to the "fixed in 3.3" catagory Revision ChangesPath 1.13 +122 -5jakarta-tomcat/RELEASE-PLAN-3.3 Index: RELEASE-PLAN-3.3 === RCS file: /home/cvs/jakarta-tomcat/RELEASE-PLAN-3.3,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- RELEASE-PLAN-3.3 2001/06/21 04:42:08 1.12 +++ RELEASE-PLAN-3.3 2001/09/13 19:57:38 1.13 @@ -147,16 +147,133 @@ 1. TBD... +Tomcat 3.3 Release Candidate 1: + + Code Freeze/Tag Date: Sept 14, 2001 + Release Manager:Larry Isaacs + + This release should be used to verify that we really are + at release quality. It should include any fixes needed + to reach that status. Documentation updates may continue + after this release. + +To Be Addressed for RC1: + +1. HttpSessionFacade.setAttribute() isn't synchronized. If a second request +called "setAttribute()" after this request's "removeAttribute()" and before +"realSession.setAttribute()", the second request's value would be overwritten +without an valueUnbound() being called. + +2. Evaluate Tomcat 3.3's vulnerability to "Double Checked Locking". This +is referred to in Bug #177. See: +http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html +for details. I think ServletHandler.init() is currently subject to this +vulnerability. + +3. The spec doesn't address whether a the form-login-page and form-error-page +should be excluded from the security-constraint, but it makes sense that +it should. It might be best to postpone this. + +4. Address user authentication via Ajp12 and Ajp13. Ajp12 has a test for +isTomcatAuthentication() to see if req.setRemoteUser() should be called. +I think Ajp13 doesn't have this yet and probably should. Also, if the +user is anonymous, i.e. user = "", should we call req.setRemoteUser() +with this value? This prevents Tomcat's normal authentication from being +triggered. + +5. If a error handler is not found for an exception, check the root cause +as well if it is a ServletException. This is mentioned in Bug 3233. I think +it would be a good idea to apply this. I don't think we are prohibited +by the spec. We could add an option to be safe if there is concern. + +6. StaticInterceptor is missing a localization enhancement added to +Tomcat 3.2.x. Should this enhancement be ported to Tomcat 3.3? Is +this still considered a regression, though it isn't part of the +Servlet 2.2/JSP 1.1 spec? + +7. Evaluate whether anything should be done to deal with the use of +non-thread-safe DateFormat and related classes. + +Must Resolve Bugs: + +177 Race condition during servlet initialization BugRat Report#2 +182 JSP error-page doesn't work with virtual hosts BugRat Report +274 request.getUserPrincipal() doesn't work when user is authent +437 req.getParameter(name) Ignores charset. always assumes ISO88 +463 Ctx( /examples ): IOException in: R( /examples + + null) No +1253 Frequent Connection reset by peer errors +1663 Tomcat -SSL problem +1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after +3233 exception handling wrt errorpages seems to be incorrect +3486 Session problem (with case insensitive context matching on windows) +3572 HttpSessionFacade.invalidate don't unbound Attributes +3577 NPE when DecodeInterceptor gets confused + +Tomcat 3.3 Release Candidate 2: + + Code Freeze/Tag Date: Sept 21, 2001 + Release Manager:Larry Isaacs + + Will be the build put to a vote as a release. This release should + only include very minor fixes and documentation updates from the + RC1 release. + +To Be Addressed by RC2: + +8. We need to remove or optionally disable the shutdown support in +Ajp13Interceptor. This allows configuring a password protected +Ajp12Interceptor shutdown to be the only shutdown available. + +9. Some files under src/native have embedded CR's, i.e. Unix files would have +CRLF and Windows files would have CRCRLF's. These need to be fixed. + +10. The jk_nt_service, and I assume jniconnect, redirect stdout and stderr to +files. With the default server.xml with no path for tc_log, Tomcat's +startup output ends up in the "stderr" log. I would have expected it to +be in the "stdout" log. Is there a reason the o.a.t.u.qlog.Logger uses +stderr as the default sink instead of stdout? + +11. Make sure we are okay with mod_jk not supporting Apache's rewrite +in Tomcat 3.3's mod_jk. I'm fine with not supporting it, but I
cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
larryi 01/06/20 21:42:10 Modified:.RELEASE-PLAN-3.3 Log: Update release plan to add Milestone 4 and adjust dates Revision ChangesPath 1.12 +21 -3 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.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- RELEASE-PLAN-3.3 2001/05/15 12:59:49 1.11 +++ RELEASE-PLAN-3.3 2001/06/21 04:42:08 1.12 @@ -80,9 +80,27 @@ structure consistent with other Jakarta projects, i.e. use jakarta-tomcat-3.3-xxx. +Tomcat 3.3 Milestone 4 Release: + + Code Freeze/Tag Date: June 20, 2001 + Release Manager:Larry Isaacs + + This release contains a switch to using jakarta-tomcat-connectors + for some utility classes. It also uses jakarta-tomcat-jasper + for building jasper34, which will be enabled as the default + JSP handler. The internal "jasper33" will be enabled as the + default JSP handler for future releases of Tomcat 3.3. + + Known issues in order of priority: + 1. Jasper34 needs to be stable. + 2. Watchdog and internal test need to be passing all tests. + 3. Build documentation need to be updated to document +new dependencies on jakarta-tomcat-connectors and +jakarta-tomcat-jasper. + Tomcat 3.3 Beta 1: - Code Freeze/Tag Date: March 26, 2001 + Code Freeze/Tag Date: July 11, 2001 Release Manager:Larry Isaacs No major change will be done after the Beta is build without a @@ -119,7 +137,7 @@ Tomcat 3.3 Beta 2: - Code Freeze/Tag Date: June 2, 2001 + Code Freeze/Tag Date: July 18, 2001 Release Manager:Larry Isaacs This release should fix any major bugs found in the @@ -131,7 +149,7 @@ Tomcat 3.3 Final Release - Code Freeze Date: June 9, 2001 + Code Freeze Date: August 1, 2001 Release Manager:Larry Isaacs The final build. The pre-requisite for the release is having no bugs in
RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
getRemoteHost() is now fixed in CVS :) Same that TC 3.2.2 - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, May 15, 2001 3:00 PM >To: [EMAIL PROTECTED] >Subject: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3 > > >larryi 01/05/15 05:59:53 > > Modified:.RELEASE-PLAN-3.3 > Log: > Update to move getRequestURI problem to Beta 1. > > Indicate requirement in Milestone 3 to check security >problem of URL's with > escape sequences being able to reveal JSP source. > > Indicate requirement in Beta 1 to address problem of >getResource() allowing > access to files outside the web application with paths >containing the right > escape sequences. > > Revision ChangesPath > 1.11 +8 -5 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.10 > retrieving revision 1.11 > diff -u -r1.10 -r1.11 > --- RELEASE-PLAN-3.3 2001/05/15 09:47:52 1.10 > +++ RELEASE-PLAN-3.3 2001/05/15 12:59:49 1.11 > @@ -75,7 +75,7 @@ > >Known issues in order of priority > > - 1. getRequestURI() should return an encoded string (if >feasible) > + 1. Verify that JSP source is not served when escaping >tricks are used >2. Update build process to create archives and >internal directory > structure consistent with other Jakarta projects, i.e. use > jakarta-tomcat-3.3-xxx. > @@ -105,13 +105,16 @@ > object in the session. The spec calls for the reverse. > B. setAttribute() doesn't call valueUnbound() for the > object it replaces, if present. > - 3. Session recyling includes keeping the >HttpSessionFacade. I believe > + 3. Fix getResource() to not allow access to files >outside of the web > +application. > + 4. Session recyling includes keeping the >HttpSessionFacade. I believe > this represents a security risk. May need to >discard session > facades, or at least discard them for untrusted web >applications. > - 4. Update getRemoteHost() to be consistent with Tomcat >3.2.2, which > + 5. getRequestURI() should return an encoded string > + 6. Update getRemoteHost() to be consistent with Tomcat >3.2.2, which > does a reverse DNS lookup. > - 5. Verify no reqressions. > - 6. TBD... > + 7. Verify no reqressions. > + 8. TBD... > > > Tomcat 3.3 Beta 2: > > > >
cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
larryi 01/05/15 05:59:53 Modified:.RELEASE-PLAN-3.3 Log: Update to move getRequestURI problem to Beta 1. Indicate requirement in Milestone 3 to check security problem of URL's with escape sequences being able to reveal JSP source. Indicate requirement in Beta 1 to address problem of getResource() allowing access to files outside the web application with paths containing the right escape sequences. Revision ChangesPath 1.11 +8 -5 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.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- RELEASE-PLAN-3.3 2001/05/15 09:47:52 1.10 +++ RELEASE-PLAN-3.3 2001/05/15 12:59:49 1.11 @@ -75,7 +75,7 @@ Known issues in order of priority - 1. getRequestURI() should return an encoded string (if feasible) + 1. Verify that JSP source is not served when escaping tricks are used 2. Update build process to create archives and internal directory structure consistent with other Jakarta projects, i.e. use jakarta-tomcat-3.3-xxx. @@ -105,13 +105,16 @@ object in the session. The spec calls for the reverse. B. setAttribute() doesn't call valueUnbound() for the object it replaces, if present. - 3. Session recyling includes keeping the HttpSessionFacade. I believe + 3. Fix getResource() to not allow access to files outside of the web +application. + 4. Session recyling includes keeping the HttpSessionFacade. I believe this represents a security risk. May need to discard session facades, or at least discard them for untrusted web applications. - 4. Update getRemoteHost() to be consistent with Tomcat 3.2.2, which + 5. getRequestURI() should return an encoded string + 6. Update getRemoteHost() to be consistent with Tomcat 3.2.2, which does a reverse DNS lookup. - 5. Verify no reqressions. - 6. TBD... + 7. Verify no reqressions. + 8. TBD... Tomcat 3.3 Beta 2:
RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
Now Tomcat 3.2.2 does DNS lookup. I'll send update to 3.3 to do that today :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >Sent: Friday, May 11, 2001 10:23 PM >To: [EMAIL PROTECTED] >Subject: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3 > > >larryi 01/05/11 13:22:59 > > Modified:.RELEASE-PLAN-3.3 > Log: > Update release plan. Issues and priorities aren't final and >will be updated > as needed. > > Revision ChangesPath > 1.9 +68 -10jakarta-tomcat/RELEASE-PLAN-3.3 > > Index: RELEASE-PLAN-3.3 > === > RCS file: /home/cvs/jakarta-tomcat/RELEASE-PLAN-3.3,v > retrieving revision 1.8 > retrieving revision 1.9 > diff -u -r1.8 -r1.9 > --- RELEASE-PLAN-3.3 2001/01/31 01:55:38 1.8 > +++ RELEASE-PLAN-3.3 2001/05/11 20:22:52 1.9 > @@ -68,11 +68,23 @@ > Should that not be the case, this release may be >skipped since the > beta release is expected a week later. > > -Tomcat 3.3 Beta: > +Tomcat 3.3 Milestone 3 Release: > > -Code Freeze/Tag Date: March 15, 2001 > +Code Freeze/Tag Date: May 12, 2001 > Release Manager:Larry Isaacs > > + Known issues in order of priority > + > + 1. getRequestURI() should return an encoded string (if >feasible) > + 2. Update build process to create archives and >internal directory > +structure consistent with other Jakarta projects, i.e. use > +jakarta-tomcat-3.3-xxx. > + > +Tomcat 3.3 Beta 1: > + > +Code Freeze/Tag Date: March 26, 2001 > +Release Manager:Larry Isaacs > + >No major change will be done after the Beta is build without a >vote. The release team can reject any change they feel >is too big >and can introduce regressions, or is not needed. > @@ -82,22 +94,68 @@ > >During the beta period we will fix all remaining bugs >and run the manual >tests for the bugs that have no automated test case. > + > + Known issues in order of priority: > + 1. Port all missing updates to Jasper from Tomcat >3.2.2 and verify that > +all Jasper theading issues are dealt with. This >includes Bugzilla > +Bugs 80,140,1039,1123,1280,1646 > + 2. Check HttpSessionFacade for spec compliance. > +Know problems: > +A. setAttribute() calls valueBound() after storing the > + object in the session. The spec calls for the reverse. > +B. setAttribute() doesn't call valueUnbound() for the > + object it replaces, if present. > + 3. Session recyling includes keeping the >HttpSessionFacade. I believe > +this represents a security risk. May need to >discard session > +facades, or at least discard them for untrusted web >applications. > + 4. Update getRemoteHost() to be consistent with Tomcat >3.2.2, if > +appropriate. In Tomcat 3.2.2, it no longer does a >reverse DNS > +lookup. > + 5. Verify no reqressions. > + 6. TBD... > + > > -Tomcat 3.3 Addition Betas: > +Tomcat 3.3 Beta 2: > > -Code Freeze/Tag Date: Weekly from March 15, 2001 > +Code Freeze/Tag Date: June 2, 2001 > Release Manager:Larry Isaacs > - > -After the first beta, we will periodically build beta >releases in > -order to track the evolution. > > + This release should fix any major bugs found in the > + prior beta and any missed regressions. > + > + Known issues in order of priority: > + 1. TBD... > + > + > Tomcat 3.3 Final Release > > -Code Freeze Date: Apr 5, 2001 > +Code Freeze Date: June 9, 2001 > 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 >approval by the community. > + > + Known issues in order of priority: > + 1. Update/fix documentation as much as possible > + > + > +Bugs That Won't Be Fixed In Tomcat 3.3 > > -The final build. The pre-requisite for the release is >having no bugs in > -the test suite, resolution for all known bugs and >approval by the community. > +The following Bugzilla Bugs are known issues that
cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
larryi 01/05/11 13:22:59 Modified:.RELEASE-PLAN-3.3 Log: Update release plan. Issues and priorities aren't final and will be updated as needed. Revision ChangesPath 1.9 +68 -10jakarta-tomcat/RELEASE-PLAN-3.3 Index: RELEASE-PLAN-3.3 === RCS file: /home/cvs/jakarta-tomcat/RELEASE-PLAN-3.3,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- RELEASE-PLAN-3.3 2001/01/31 01:55:38 1.8 +++ RELEASE-PLAN-3.3 2001/05/11 20:22:52 1.9 @@ -68,11 +68,23 @@ Should that not be the case, this release may be skipped since the beta release is expected a week later. -Tomcat 3.3 Beta: +Tomcat 3.3 Milestone 3 Release: - Code Freeze/Tag Date: March 15, 2001 + Code Freeze/Tag Date: May 12, 2001 Release Manager:Larry Isaacs + Known issues in order of priority + + 1. getRequestURI() should return an encoded string (if feasible) + 2. Update build process to create archives and internal directory +structure consistent with other Jakarta projects, i.e. use +jakarta-tomcat-3.3-xxx. + +Tomcat 3.3 Beta 1: + + Code Freeze/Tag Date: March 26, 2001 + Release Manager:Larry Isaacs + No major change will be done after the Beta is build without a vote. The release team can reject any change they feel is too big and can introduce regressions, or is not needed. @@ -82,22 +94,68 @@ During the beta period we will fix all remaining bugs and run the manual tests for the bugs that have no automated test case. + + Known issues in order of priority: + 1. Port all missing updates to Jasper from Tomcat 3.2.2 and verify that +all Jasper theading issues are dealt with. This includes Bugzilla +Bugs 80,140,1039,1123,1280,1646 + 2. Check HttpSessionFacade for spec compliance. +Know problems: +A. setAttribute() calls valueBound() after storing the + object in the session. The spec calls for the reverse. +B. setAttribute() doesn't call valueUnbound() for the + object it replaces, if present. + 3. Session recyling includes keeping the HttpSessionFacade. I believe +this represents a security risk. May need to discard session +facades, or at least discard them for untrusted web applications. + 4. Update getRemoteHost() to be consistent with Tomcat 3.2.2, if +appropriate. In Tomcat 3.2.2, it no longer does a reverse DNS +lookup. + 5. Verify no reqressions. + 6. TBD... + -Tomcat 3.3 Addition Betas: +Tomcat 3.3 Beta 2: - Code Freeze/Tag Date: Weekly from March 15, 2001 + Code Freeze/Tag Date: June 2, 2001 Release Manager:Larry Isaacs - -After the first beta, we will periodically build beta releases in -order to track the evolution. + This release should fix any major bugs found in the + prior beta and any missed regressions. + + Known issues in order of priority: + 1. TBD... + + Tomcat 3.3 Final Release - Code Freeze Date: Apr 5, 2001 + Code Freeze Date: June 9, 2001 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 approval by the community. + + Known issues in order of priority: + 1. Update/fix documentation as much as possible + + +Bugs That Won't Be Fixed In Tomcat 3.3 -The final build. The pre-requisite for the release is having no bugs in -the test suite, resolution for all known bugs and approval by the community. +The following Bugzilla Bugs are known issues that are not planned to be +addressed in Tomcat 3.3. + +Bug #75: Translation time attribute evaluation not provided to + TagExtraInfo class +Bug #143: Tag handlers with properties of type "Object" +Bug #155: Quick Blurb saying "Everything is initialized" +Bug #164: IIS Logging +Bug #203: `tomcat.sh env` ruins the shell if $TOMCAT_HOME is not set +Bug #451: ServletException displaying wrong lines in debug information +Bug #481: Misleading exception report +Bug #524: Can't use Apache SSI with mod_jserv +Bug #631: RequestDispatcher.include output is in wrong order +Bug #1057: Context Paths and numerals. +Bug #1433: Comments are parsed inside tag. Release criteria
cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
larryi 01/01/30 17:55:38 Modified:.RELEASE-PLAN-3.3 Log: Update per Jon's suggestion. I specified "resolved", as supported by Bugzilla, to indicate that some bugs may not be fixed. But, as Jon requested, we need to make sure all bugs are addressed. None should slip through unnoticed. Revision ChangesPath 1.8 +3 -1 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.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- RELEASE-PLAN-3.3 2001/01/30 16:03:07 1.7 +++ RELEASE-PLAN-3.3 2001/01/31 01:55:38 1.8 @@ -118,7 +118,9 @@ 4. Jasper must include bug fixes that were done in both 3.2.x and 4.0, and various enhancements that are deemed appropriate. -5. Bugs found after and during 3.2 release cycle should be fixed, if possible. +5. All bugs that have been opened after the Tomcat 3.2.1 release will be + resolved before a 3.3 release is made. "Resolved" means that one of the + "resolutions" supported by BugZilla has been assigned to the bug. 6. Full review of the code, making sure the modularity and extensibility goals have been achieved. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
larryi 01/01/30 08:03:12 Modified:.RELEASE-PLAN-3.3 Log: Final update. Modify to not promise to fix all bugs. Update Release Criteria 9 to better specify its scope. Revision ChangesPath 1.7 +6 -4 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.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- RELEASE-PLAN-3.3 2001/01/30 14:50:14 1.6 +++ RELEASE-PLAN-3.3 2001/01/30 16:03:07 1.7 @@ -110,7 +110,7 @@ Any reported regression is a show-stopper and a release can't be made before it is resolved. -2. Open bugs should be resolved. +2. Open bugs should be fixed, if possible. 3. Tomcat 3.3 should be tested with existing, complex applications ( cocoon, bugrat, etc ). @@ -118,7 +118,7 @@ 4. Jasper must include bug fixes that were done in both 3.2.x and 4.0, and various enhancements that are deemed appropriate. -5. Bugs found after and during 3.2 release cycle should be fixed. +5. Bugs found after and during 3.2 release cycle should be fixed, if possible. 6. Full review of the code, making sure the modularity and extensibility goals have been achieved. @@ -129,8 +129,10 @@ 8. Ensure that the performance is (significantly) better than 3.2 -9. Ensure that Jasper is compatible ( as much as possible ) with the - version used in the proposed 4.0. +9. Ensure that Jasper is compatible (as much as possible) with the + version used in the proposed 4.0. This refers to behavior differences + outside of the JSP spec, which could create problems moving a + web application from Tomcat 3.3 to Tomcat 4.x. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
larryi 01/01/30 06:50:18 Modified:.RELEASE-PLAN-3.3 Log: Move Milestone 1 back a week and fix Milestone 2 to be about midway between Milestone 1 and Beta 1. Fix some indentation. Revision ChangesPath 1.6 +5 -5 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.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- RELEASE-PLAN-3.3 2001/01/23 20:45:07 1.5 +++ RELEASE-PLAN-3.3 2001/01/30 14:50:14 1.6 @@ -30,7 +30,7 @@ Tomcat 3.3 Milestone 1 Release: - Code Freeze/Tag Date: Feb 1, 2001 + Code Freeze/Tag Date: Feb 8, 2001 Release Manager:Larry Isaacs To help insure widespread testing, this build must include an acceptably @@ -57,16 +57,16 @@ Tomcat 3.3 Milestone 2 Release: - Code Freeze/Tag Date: Feb 8, 2001 + Code Freeze/Tag Date: March 1, 2001 Release Manager:Larry Isaacs This release is optional depending on the amount of bug fixing that - occurs since the milestone 1 release. The major goal of the week +occurs since the milestone 1 release. The major goal of the week following milestone 1 will be to identify what further work is needed based on the feedback. During this time it is hoped that there will be enough bug fixes and tests added to make this release worthwhile. - Should that not be the case, this release may be skipped since the - beta release is expected a week later. +Should that not be the case, this release may be skipped since the +beta release is expected a week later. Tomcat 3.3 Beta: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat RELEASE-PLAN-3.3 STATUS.html
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 ChangesPath 1.5 +17 -16jakarta-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 -18jakarta-tomcat/STATUS.html Index: STATUS.html
cvs commit: jakarta-tomcat RELEASE-PLAN-3.3 STATUS.html
larryi 01/01/22 13:21:45 Modified:.RELEASE-PLAN-3.3 STATUS.html Log: Some updates the schedule and move open items to STATUS.html. Filled in my name as Release Manager. Added action items to the Release Preparation section of STATUS.html. I'll make another pass through these documents, but at this time I don't have any major changes planned. Comments welcome. Especially if I am missing something that is required by previous agreements. Revision ChangesPath 1.4 +30 -43jakarta-tomcat/RELEASE-PLAN-3.3 Index: RELEASE-PLAN-3.3 === RCS file: /home/cvs/jakarta-tomcat/RELEASE-PLAN-3.3,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- RELEASE-PLAN-3.3 2001/01/20 19:28:20 1.3 +++ RELEASE-PLAN-3.3 2001/01/22 21:21:44 1.4 @@ -1,4 +1,4 @@ -NOTE: This document is the first cut at a release plan for the next +NOTE: This document is a draft of a release plan for the next dot release of Tomcat. Nothing in this document should be considered authoritative until it has been discussed and approved on the TOMCAT-DEV mailing list. @@ -26,32 +26,15 @@ 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. -Open items ( XXX move to STATUS ): - -This list includes changes that need to be done in 3.3 - -1. Integrate the bug fixes from 3.2 that haven't been integrated/fixed - so far. - -2. Review the code changes and do the required changes, and produce - documentation for the resulting code. - -3. If time permits, enable the use of the Parameters and Headers classes. - -4. Fix the encoding bugs ( reported by Larry ) -5. Improve the test suite. - -6. Add a "credits.html" ( or similar ) with information about the - +1 commiters that made the release possible and all the volunteers - that contribute to it. Given the ammount of responsiblity and - work that is required I think this is an absolute requirement. - Tomcat 3.3 Milestone 1 Release: - Code Freeze/Tag Date: Feb 1, 2001 (?) - Release Manager:??? + Code Freeze/Tag Date: Feb 1, 2001 + Release Manager:Larry Isaacs +To help insure widespread testing, this build must include an acceptably +simple way of running the internal Tomcat tests and Watchdog in some form. + The build must pass all watchdog and all existing test suites. It should work on both JDK1.1 and JDK1.2. @@ -71,16 +54,23 @@ We must test and make sure that JspServlet still function properly. -Tomcat 3.3 periodical milestones: - -After the first milestone, we will periodically build milestones in -order to track the evolution. ( see also the testing plan at the end ). -The release manager will build and make them available. +Tomcat 3.3 Milestone 2 Release: + Code Freeze/Tag Date: Feb 8, 2001 + Release Manager:Larry Isaacs + +This release is optional depending on the amount of bug fixing that + occurs since the milestone 1 release. The major goal of the week +following milestone 1 will be to identify what further work is needed +based on the feedback. During this time it is hoped that there will +be enough bug fixes and tests added to make this release worthwhile. + Should that not be the case, this release may be skipped since the + beta release is expected a week later. + Tomcat 3.3 Beta: - Code Freeze/Tag Date: March 15, 2001 (?) - Release Manager:??? + Code Freeze/Tag Date: March 15, 2001 + Release Manager:Larry Isaacs No major change will be done after the Beta is build without a vote. The release team can reject any change they feel is too big @@ -92,10 +82,18 @@ During the beta period we will fix all remaining bugs and run the manual tests for the bugs that have no automated test case. +Tomcat 3.3 Addition Betas: + + Code Freeze/Tag Date: Weekly from March 15, 2001 + Release Manager:Larry Isaacs + +After the first beta, we will periodically build beta releases in +order to track the evolution. + Tomcat 3.3 Final Release - Code Freeze Date: Apr 5, 2001 (?) - Release Manager:??? + Code Freeze Date: Apr 5, 2001 + 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. @@ -179,14 +177,3 @@ responsible for building the milestones, making the announcements about the releas
cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
costin 01/01/20 11:28:21 Modified:.RELEASE-PLAN-3.3 Log: Added a paragraph about the release team and release manager, listing the current volunteers. ( the final list will be of course decided in the voting process ). Added an action item to add a credits page with the members of the release team ( will be part of the standard distribution, so people can contact the right persons ). Revision ChangesPath 1.3 +31 -0 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.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- RELEASE-PLAN-3.3 2001/01/19 03:28:00 1.2 +++ RELEASE-PLAN-3.3 2001/01/20 19:28:20 1.3 @@ -42,6 +42,11 @@ 5. Improve the test suite. +6. Add a "credits.html" ( or similar ) with information about the + +1 commiters that made the release possible and all the volunteers + that contribute to it. Given the ammount of responsiblity and + work that is required I think this is an absolute requirement. + Tomcat 3.3 Milestone 1 Release: Code Freeze/Tag Date: Feb 1, 2001 (?) @@ -158,4 +163,30 @@ The release team must coordinate the maintainace 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 ++1 on the release plan and release proposal. It must have at least 3 +memebers, 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 +process. + +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. + +Larry Isaacs has volunteered as a Release Manager, and Henri Gomez has + volunteered to act as a backup and help on the Unix side. So far, 4 people +had volunteered to be part of the release team - Ignacio Ortega (Nacho) +and Costin Manolache are the other 2. The final team will be determined +by the vote that will take place, any commiter voting a binding +1 becoming +a member of the Release Team. It is possible for a team member to retire as + long as the minimum of 3 members is maintained, and one of the members agrees +to act as Release Manager. + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
I also think it would be good idea to require Jasper's JspServlet still function properly if used in Tomcat 3.3, even though Tomcat 3.3 now uses an interceptor to manage JSP compilation. (Jasper is still used for translation to servlet source, but the interceptor controls the rest). +1 (We use Jasper inside Weblogic's servlet container, and so don't have/use the interceptor) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
costin 01/01/18 19:28:00 Modified:.RELEASE-PLAN-3.3 Log: - incorporate Jon's suggestions: specify that the release team will coordinate the support, the milestones will be periodical,based on the RM decision, +1 commiters will decide what goes in during beta, added mention for the extra OSs. - incorporate Larry's sugestions ( Jasper, JspServlet ) - incorporate Hans sugestions ( move the goals to release criteria, added a note regarding the new features and STATUS, added a list of open items ) Some notes: - I don't think we can add a requirement that all bugs have test cases. This is sometimes impossible, and AFAIK no other apache project is doing that. - MacOS ( and FreeBSD ) are optional - most current developers are not using them, and this would be a too big burden. We'll try to get people using those OSes to contribute test reports. Revision ChangesPath 1.2 +61 -26jakarta-tomcat/RELEASE-PLAN-3.3 Index: RELEASE-PLAN-3.3 === RCS file: /home/cvs/jakarta-tomcat/RELEASE-PLAN-3.3,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- RELEASE-PLAN-3.3 2001/01/18 07:38:23 1.1 +++ RELEASE-PLAN-3.3 2001/01/19 03:28:00 1.2 @@ -14,22 +14,33 @@ of jakarta-tomcat 3.x and achieve the stated goals of providing a production quality 2.2/1.1 servlet container. -Goals: -The following goals should be met in executing this plan: +Changes: -1. No regressions compared with 3.2. +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 ) -2. Fixing the bugs found after and during 3.2 release cycle. +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. -3. Full review of the code, making sure the modularity and - extensibility goals have been achieved. - -4. Make sure that the refactoring is clean, and maintainance will be - easier that 3.2 +Open items ( XXX move to STATUS ): + +This list includes changes that need to be done in 3.3 + +1. Integrate the bug fixes from 3.2 that haven't been integrated/fixed + so far. + +2. Review the code changes and do the required changes, and produce + documentation for the resulting code. + +3. If time permits, enable the use of the Parameters and Headers classes. + +4. Fix the encoding bugs ( reported by Larry ) -5. Ensure that the performance is (significantly) better than - 3.2 +5. Improve the test suite. Tomcat 3.3 Milestone 1 Release: @@ -44,19 +55,22 @@ discussed and incorporated. Also, the documentation will be reviewed and improved. -In paralel, work will start on fixing a significant number ( most ? ) of +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 continue during the beta period. Whenever possible, we should try to create a self-test case ( using the current self-test application and GTest ). -More documentations should be added on running GTest and simplify the -test application. +It is desirable to add more documentation on running GTest and the +test application, to simplify the testing work. -Tomcat 3.3 BiWeekly milestones: +We must test and make sure that JspServlet still function properly. + +Tomcat 3.3 periodical milestones: After the first milestone, we will periodically build milestones in order to track the evolution. ( see also the testing plan at the end ). +The release manager will build and make them available. Tomcat 3.3 Beta: @@ -64,7 +78,8 @@ Release Manager:??? No major change will be done after the Beta is build without a - vote. + vote. The release team can reject any change they feel is too big + and can introduce regressions, or is not needed. No major bug ( spec compliance or stability ) should be open in order to enter beta. @@ -84,9 +99,8 @@ Release criteria -Given that this will be proposed as the final release of tomcat3.x the -standards of quality and testing will be significantly higher than in - previous releases. +The standards of quality and testing will be significantly higher than in +previous releases. 1. Tomcat 3.3 should have no reg
Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
Larry Isaacs wrote: > A couple of comments: > > I would like to see a goal added like the following: > > X. With respect to JSP 1.1 issues, insure that Jasper in Tomcat 3.3 > remains compatible with Jasper in Tomcat 4.x. > Larry, are you thinking of "compatibility" from the functional viewpoint (i.e. every JSP page that works in 3.x works the same in 4.x) or from a code sharing viewpoint? The former is something I would definitely favor -- backwards compatibility in Tomcat 4.x is mandated by the specs, and having people actively concerned about cross-checking is a useful mechanism to ensure it. The latter, on the other hand, would be pretty difficult to achieve, because Jasper in 4.x needs to be free to use Java2 classes where appropriate. I'm also interested in looking at some more radical changes in Jasper that improve the performance of the code that is generated. > > and under Release criteria something like: > > X. Port all appropriate JSP 1.1 related changes from Tomcat 4.x Jasper > to Tomcat 3.3 Jasper. This includes all JSP 1.1 related bug fixes and > all issues that would affect upgrading from JSP 1.1 to 1.2 should also > be included. Other issues, such as name munging changes, may be included > if deemed appropriate (with Vote if necessary). > > I also think it would be good idea to require Jasper's JspServlet still > function properly if used in Tomcat 3.3, even though Tomcat 3.3 now uses > an interceptor to manage JSP compilation. (Jasper is still used for > translation to servlet source, but the interceptor controls the > rest). > Makes sense. > > Cheers, > Larry > Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
A couple of comments: I would like to see a goal added like the following: X. With respect to JSP 1.1 issues, insure that Jasper in Tomcat 3.3 remains compatible with Jasper in Tomcat 4.x. and under Release criteria something like: X. Port all appropriate JSP 1.1 related changes from Tomcat 4.x Jasper to Tomcat 3.3 Jasper. This includes all JSP 1.1 related bug fixes and all issues that would affect upgrading from JSP 1.1 to 1.2 should also be included. Other issues, such as name munging changes, may be included if deemed appropriate (with Vote if necessary). I also think it would be good idea to require Jasper's JspServlet still function properly if used in Tomcat 3.3, even though Tomcat 3.3 now uses an interceptor to manage JSP compilation. (Jasper is still used for translation to servlet source, but the interceptor controls the rest). Cheers, Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
I'm not a committer, but just to add my $.02, this release plan looks very good, and seems like it meets my goals as a user/developer, and those of the community. I hope it gets approved, since it seems like a lot of good work has gone into this, and better yet, we'll have been able to finally resolve this issue through the proper process. Matt Pangaro Loki Technologies - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, January 18, 2001 2:38 AM Subject: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3 > costin 01/01/17 23:38:24 > > Added: .RELEASE-PLAN-3.3 > Log: > Initial checkin for the release proposal. > > Revision ChangesPath > 1.1 jakarta-tomcat/RELEASE-PLAN-3.3 > > Index: RELEASE-PLAN-3.3 > === > NOTE: This document is the first cut at a release plan for the next > dot release of Tomcat. Nothing in this document should be > considered authoritative until it has been discussed and approved > on the TOMCAT-DEV mailing list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
on 1/17/01 11:38 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > costin 01/01/17 23:38:24 > > Added: .RELEASE-PLAN-3.3 You are missing the word "support" in this entire document. It has already been stated that it is a *requirement* in the PMC meeting that in order for a release to occur, the concern about *support* *must* be addressed. > Goals: 6. User documentation must be reviewed and improved. For example, any new or changed configuration parameters should be documented. > paralel parallel > More documentations should be added on running GTest and simplify the > test application. *should* or *must*? > Tomcat 3.3 BiWeekly milestones: I think you should specify what days of the week if you are going to say biweekly. Lets make this consistent and regular, otherwise, don't specify "BiWeekly". > No major change will be done after the Beta is build without a > vote. What constitutes a "major" change? Because you seem to waffle on what a "major" change means, I want clarification. > Platorms. > We must make sure that tomcat is tested ( at least watchdog + self-test ) > with at least Linux, Solaris, Windows 9x, Windows NT/2000. Add MacOS9 here. The reason is that there are commercial vendors (two that I know of) that are producing releases that include Tomcat 3.x. They should be able to release stock versions of Tomcat 3.x. > After tomcat 3.3 is released, no major development should go on into the main > branch. I don't agree with that. If someone proposes it and it is agreed upon, then it should be allowed. However, it should not be declared with a version number. > During the beta period we will fix all remaining bugs and run the manual > tests for the bugs that have no automated test case. Shouldn't it be a requirement that all software bugs have test cases? Again, this backs up into the support issue. > The release team should consist of at least 3 people, This part should be near the top, not at the bottom. Also, what is the *must* here? What is the minimum number of people? -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
costin 01/01/17 23:38:24 Added: .RELEASE-PLAN-3.3 Log: Initial checkin for the release proposal. Revision ChangesPath 1.1 jakarta-tomcat/RELEASE-PLAN-3.3 Index: RELEASE-PLAN-3.3 === NOTE: This document is the first cut at a release plan for the next dot release of Tomcat. Nothing in this document should be considered authoritative until it has been discussed and approved on the TOMCAT-DEV mailing list. Tomcat 3.3 Release Plan === Objective: The objective of the proposed 3.3 release is to complete the development of jakarta-tomcat 3.x and achieve the stated goals of providing a production quality 2.2/1.1 servlet container. Goals: The following goals should be met in executing this plan: 1. No regressions compared with 3.2. 2. Fixing the bugs found after and during 3.2 release cycle. 3. Full review of the code, making sure the modularity and extensibility goals have been achieved. 4. Make sure that the refactoring is clean, and maintainance will be easier that 3.2 5. Ensure that the performance is (significantly) better than 3.2 Tomcat 3.3 Milestone 1 Release: Code Freeze/Tag Date: Feb 1, 2001 (?) Release Manager:??? The build must pass all watchdog and all existing test suites. It should work on both JDK1.1 and JDK1.2. After the build of Milestone 1, work should start in reviewing all the classes and interfaces in tomcat.core, and any feedback should be discussed and incorporated. Also, the documentation will be reviewed and improved. In paralel, 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 continue during the beta period. Whenever possible, we should try to create a self-test case ( using the current self-test application and GTest ). More documentations should be added on running GTest and simplify the test application. Tomcat 3.3 BiWeekly milestones: After the first milestone, we will periodically build milestones in order to track the evolution. ( see also the testing plan at the end ). Tomcat 3.3 Beta: Code Freeze/Tag Date: March 15, 2001 (?) Release Manager:??? No major change will be done after the Beta is build without a vote. No major bug ( spec compliance or stability ) should be open in order to enter beta. During the beta period we will fix all remaining bugs and run the manual tests for the bugs that have no automated test case. Tomcat 3.3 Final Release Code Freeze Date: Apr 5, 2001 (?) Release Manager:??? 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. Release criteria Given that this will be proposed as the final release of tomcat3.x the standards of quality and testing will be significantly higher than in previous releases. 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. 2. Open bugs should be resolved. 3. Tomcat 3.3 should be tested with existing, complex applications ( cocoon, bugrat, etc ). Platorms. We must make sure that tomcat is tested ( at least watchdog + self-test ) with at least Linux, Solaris, Windows 9x, Windows NT/2000. JDK. We must test tomcat with at least JDK1.1 and Java2 (multiple versions if possible) . The tests should also include a stress test ( a high load "ab" running for a long time ) Configurations Tomcat must be tested standalone, with Apache 1.3, Apache 2.0 and ( possibly ) with IIS and NES ( low priority ). Maintainance Plan = After tomcat 3.3 is released, no major development should go on into the main branch. The release team should consist of at least 3 people, and will fix any major bugs that will be found after the 3.3 release, and propose to the group minor releases, if absolutely needed ( security or stability bugs ). In any case, no backward-incompatible or major changes should be made. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
