Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <38ECB069.F99ECC3C@eng.sun.com>
Date: Thu, 06 Apr 2000 08:42:33 -0700
From: "Craig R. McClanahan" <Craig.McClanahan@eng.sun.com>
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: possible Tomcat 3.1 issues
References: <852568B9.004390C8.00@d54mta04.raleigh.ibm.com>
 <38ECA83D.7D480D4D@eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Costin Manolache wrote:

> Regarding XML output - I can remove the <xml>-like formating
> for all "normal" message today. For debug messages - most
> people will never see them, so I would let them in - with hope that
> in next release we'll be able to implement a better solution.

This issue was unusual in that it was at least talked about (on
TOMCAT-DEV a little), but I don't recall a formal (or even informal)
public vote on the outcome.

Too many design decisions have gotten made with no public discussion or
vote.  That's something I intend to see change as we move forwards.

>
> It seems the problem is not if we want xml or not ( most people
> agree there are advantages in using an easy-to-parse format),
> but in how it is implemented, and the fact that we don't
> generate plain text too.

The implementation was, like several things, done too quickly to be
generalized correctly -- we need to stay aware that different people have
different needs.  How do we know what those needs are?  By talking about
the goals we are trying to accomplish first, then talking about
implementation.

>
> Please, let's mark the workspace and create the 3.1 RC this week
> - it seems only few people are working on bugs, and we stoped
> all development for  too long ( almost 3 weeks ).

See the RELEASE-PLAN document (top level directory), which we seem to be
following pretty accurately:

* Code freeze on 4/2 (only bug fixes after that point)
* Tag date 4/7 (still seems reasonable if we pitch in and fix
  or defer the remaining issues).


>
> This is not the last tomcat - we'll have 3.2, 3.3, etc ( I hope ) -
> the release cycle is far too long for an open source project.

In the mean time, there are people that actually want to USE this thing
in production environments.  Unless we practice the disciplines that have
made the other big open source projects successful (Apache, Linux, ...),
and create high quality releases, that's not going to happen.  The way to
do that is to exercise the software engineering disciplines required --
open source or not makes no difference.

>
> Costin

Craig McClanahan