tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Algesten <>
Subject Re: production quality?
Date Wed, 30 Oct 2002 18:54:22 GMT
Hmm... perhaps not drop it after all. I had a think about it and I still 
would argue that the amount of developers or the speed of turning out 
fixes is not the issue. As I said before, we are all doing this more or 
less for fun.

Taking on board that its all about expectations and that you need to 
test your software before deploying it and that 4.1.12 can be 
definitelly considered production quality for certain uses. There is 
still a big difference between 3.3.1 and 4.1.12, the former seems to be 
a more solid piece of software than the latter, and still they both 
enjoy the same status on the Tomcat home page. Isn't just the sheer 
amount of bug reports an argument in my direction?


Remy Maucherat wrote:

> Martin Algesten wrote:
>> Hi all,
>> Just some thoughts.
>> I've been using the 3.3.1 release for quite some time in a
>> mod_jk/apache/linux kind of setup and all was fine. Though a couple of
>> weeks ago I felt a need to start looking at new versions of all my
>> API's/products in order to make sure I stay on top of things and don't
>> end up with unsupported versions.
>> What do we mean with production quality?
>> According to the Tomcat project home page, 4.1.12 is a production
>> quality release, however using it in real life makes me question the
>> usefulness of such status. I've been monitoring this list and also tried
>> to contribute by discussing/submitting patches for the bugs I've
>> encountered. I don't have an issue with how long it takes to resolve
>> these issues, after all we are all doing this for fun (more or less ;)
>> ). However I do think we have a responsibility in what signals we're
>> sending regarding how useful a release really is. The current 4.1.12
>> release have some quite nasty issues that in some production setups
>> makes it more or less useless. In my opinion the most nasty issues are
>> those that directly breaks internet standards and the core API (10373,
>> 13846, 13040).
> 10373: I'm not convinced by the validity of the report.
> 13040: The spec is IMO not implementable, and most of the patches 
> submitted were wrong. Hence, the issue is not fixed. Sorry.
> 13846: This is a minor bug (IMHO) which will need a rather risky 
> refactoring of the headers handling to fix, hence I decided to 
> postpone fixing it.
> Unfortunaltely, there's simply not enough developers to handle the 
> amount of bug reports being filed. If the report is not crystal clear 
> or is not easy to reproduce and investigate, then no one will look 
> into it.
> The only way we could improve on this is that more people like you 
> stepped in and helped fix bugs and investigate issues. Unfortunately, 
> fixing bugs is not fun, and it doesn't happen very often (people 
> prefer to complain about their favorite BZ report instead) :-(
> Remy
> --
> To unsubscribe, e-mail:   
> <>
> For additional commands, e-mail: 
> <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message