tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: [VOTE] Send trunk to the sandbox
Date Wed, 22 Aug 2007 18:26:21 GMT
Filip Hanik - Dev Lists wrote:
> Remy Maucherat wrote:
>> Jim Jagielski wrote:
>>> IMO, code talks, bullshit walks. And I've been on both sides
>>> of the argument many times in many places.
>> Yeah right. So to summarize, we have 3 committers who are happy 
>> campers (2 of them which don't contribute much, as far as I know), and 
>> the rest of the committers are either do not care or are unhappy. Most 
>> also want a change in the development process, and as long as there's 
>> agreement on that and it respects the ASF principles, we should be 
>> able to do that.
>> It's fairly obvious that vetoes which "pack a lot of punch" haven't 
>> been taken very seriously. The first reaction is to start arguing that 
>> "the veto is not valid", and requalify technical reasons given as "non 
>> technical".
> you mean like the veto for the 5.5 B2C converter fix, where you and the 
> person vetoing hadn't even looked at the patch before writing "technical 
> reasons"
> you're kidding yourself at this point

Of course :) He said he would veto if NIO APIs usage was introduced in 
Tomcat 5.5, and that seemed reasonable to me. If there is no NIO usage, 
there will be no veto, so again what is it you do not understand ?

I see you also don't care about my reservations on the virtual CL hack. 
Any comment/discussion/collaboration on that issue ?

The technical veto only thing does not make sense to me overall. If 
"technical preference" is not allowed, then I can simply overwrite your 
Comet API in your playground (trunk) with my interpretation of it, and 
you cannot do anything about it. I think ASF project management is broken :|


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

View raw message