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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
