tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
Subject Re: [VOTE] Send trunk to the sandbox
Date Wed, 22 Aug 2007 18:49:26 GMT
Remy Maucherat wrote:
> 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 ?
both of you enforced the veto without ever looking at the real patch, so 
there was a veto thrown without justification. It should have never even 
been out there, and then dared to accuse me of not reading the posts, 
when in fact you hadn't read it yourself. I found the fact that you are 
trying to turn around that accusation here appalling. just go back and 
read your previous post on the matter... oh wait, I was the one not 
reading the post ;) must be my fault again.
>
> I see you also don't care about my reservations on the virtual CL 
> hack. Any comment/discussion/collaboration on that issue ?
feel free to start another thread on that topic,more appropriate than 
here, but i will comment
you dislike it cause it is outside of the servlet spec, but the spec 
writers don't manage hundreds and even thousands of webapp/tomcat 
instances daily that have to deal with central repositories of approved 
licensed libraries. The virtual webapp loader is an optional component, 
and very useful to those large companies.
The idea came from direct feedback from a few companies that needed 
those features.
For folks, like yourself, that dislike those features, it is an optional 
component that needs to be configured, they will never even have to use 
it. Its not in the default configuration.

As for portability, that wasn't the goal with the virtual webapp loader 
when it was added to the repository in the first place, I just made it 
more usable. I don't see any harm done with it, except that it now 
works, whereas before it really didn't.

> 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 :|
not broken at all, you're the one who refused a vote on the Comet API, 
then you try to overthrow it by throwing away trunk. had you just agreed 
to resolve the Comet issue instead of starting the "trunk" debate, it 
would have probably been resolved by now, and now of this would have 
been necessary. But it is what it is, do whatever you want with it, you 
seem so passionate about it that there is no limit to who you attack 
about it.

I'm out of the trunk debate, what ever gets decided, I'll limp along.

Filip

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message