tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ru...@us.ibm.com
Subject Release planning (was some jsp pages fail & Tomcat.next)
Date Thu, 06 Jan 2000 19:50:28 GMT


Let me start off by saying that I'm with Costin and Stefano.  There seems
to be no general disagreement at to where the destination should be, but my
experience is that neither "stop the world while I make this change" or
"let me go my own way for a while, I'm sure we can resynch later" work
terribly well.

And, I'm not sure I agree with Craig that this will increase the overall
workload.  I often find the working under the condition that the system is
always supposed to be working tends to make one work smarter rather than
harder.  It also tends to surface bad assumptions earlier.  For what it is
worth, that's my experience - your mileage may vary.

And if working harder means distributing the work a bit, then so much the
better.  No one will be upset if (with sufficient warning), someone were to
say (for example) "I need to commit the following change to the Tomcat core
in order to make more progress, and I know it breaks some little used
feature of JSP, but I don't have time to debug it at the moment, can
someone who knows that area more take a look at it for me?".

Speaking of "release early and often" (I know, lousy segway, but ...):

There have been a number of fixes made since 3.0 which increase the number
of operating system, JVM levels, and external components (such as cocoon)
supported.  I know of a few pending patches (example: EBCDIC tolerance)
which will increase this even further.

Given this state, I think we need to lay out a plan and target for a 3.1
release.  Focus is stability and platform coverage.Included in the exit
criteria is the jakarta and watchdog tests all passing on all key platforms
(TBD, but to include at a minimum, Solaris, Linux, and Win32), and a series
of "release candidates" allowing for the "burn in period" that several
people have referred to.  Architecture changes which perhaps enable further
work and are not in conflict with these goals are welcome.

There has been talk of rotating the "release manager" responsibilities.
I'll even go so far as to step forward and volunteer to do this for  3.1.
I'll admit to being extremely anal about starting from a clean check out,
and publishing and automating the process of building the binary
distribution.  I think that this would be good for the project, and helpful
for the next person who gets this job.

- Sam Ruby



Mime
View raw message