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 17:39:40 GMT
I'm dropping my argument about labelling now. It will probably not lead 
anywhere anyway.


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