Filip Hanik - Dev Lists wrote:
you start to sound like you believe yourself by this point.
After my vacation, I'll pull out the emails you wrote, where, even
though it was a veto, you clearly specified to leave it in.
I will also pull out the email, where I offered to elaborate more, and
you pretty much declined.
Then I will pull out the email where I offered to pull out the much
debated Comet implementation, so that trunk can move forward.
And if you wish, I can pull out even more examples. Just let me know how
much time and proof it needs to take before your willing to re-evaluate
your accusatory statements.
I don't know why I would not "believe myself". What I wrote is:
- trunk is your own development branch, and that significant changes are
not even discussed
- moving trunk to the sandbox is somehow characterized as "throwing it away"
- I did do comparable development in the sandbox, so I suppose I was
throwing my code away
You can post archives (that are from a few weeks ago anyway, hopefully
people here do remember) if you'd like to attempt to show I'm a bad
person or something, but there's nothing related to the issues I brought
forward in them.
In a regular branch like trunk, I expect collaboration, discussion and
announcements of upcoming changes, etc, which did not happen.
you're having a control issue, and your manifesting it by wanting to get
rid of trunk, even though several people have politely and respectfully
asked for it to remain. Mainly the Geronimo folks who would want it in
their distribution. Getting rid of trunk, simply means that Geronimo has
one more obstacle to get around, sounds like it would benefit someone
else, doesn't it?....
I proposed to move trunk to the sandbox (not delete it, obviously)
because I felt the development process is not appropriate. Development
can continue on it in the sandbox. The vote has now passed, so do you
agree to move the branch ?
Geronimo chose to rely on a development branch which did not even have a
release plan in place. The interface used in 6.0.x has marginally
inferior capabilities (it doesn't allow constructor injection, which is
not required by anything at the moment). This would create a limitation
about the web component for now, and that's about it. Overall, what they
chose to do does sound risky to me.
I would like to point out that I accepted their patch after a few
modifications, although I don't particularly like Geronimo, and this
meant more work for me in my real job (adapting JBoss to the new
interface was not so easy and took me one day of work :( ).
However, to compare with your way of doing things, if David Jencks was
acting like you are, he would have done the follwing. He would have
committed his original patch without accepting my modifications, and I
would have loudly complained about it (probably one of these "non
justified" vetoes ...). I suppose complaints would have been ignored,
with the only option for me to go "dump" my stuff in the sandbox and
then suggestions to default on innocent third parties - aka, vote on the
two injection APIs (where, similar to Comet, I bet only 2 people max care).
Despite your posturing as the knight with the shiny armor, this is not
the proper way to do things (at least if you don't want to end up being
dragged in never ending conflicts). I think I'm not asking for a lot
overall.
Besides annotations and comet, the changes in trunk are of a bug
fix/feature improvement type, and discussing every minor detail would be
equivalent to RTC. Currently we are using CTR, hence you get the option
to review anything that has been done.
This is obviously not RTC, this is normal, detailed discussion of
significant changes, such as API changes. You have shown you did not
care about comments after commit, and preferred to default to
meaningless votes to resolve problems after they escalated (that you
would not feel like abiding to if they do not turn out in your favor, I
suppose :| ).
I will also assert there are very few actual changes in trunk that would
take time to apply:
- some NIO connector changes
- clustering changes
- the annotation injection change
That's quite easy to apply to 6.0.x. Even if trunk was deleted outright,
it would seem it would take mere hours to recreate it.
I've never ignored your emails, nor have I not answered anytime you
asked for an explanation. Take the virtual loader for example, huge
improvements to a component that wasn't really working, but was included
in the main distribution. Simply because you "didn't like it" was your
explanation, doesn't make it immensely useful for very large
installation of Tomcat.
It is "I don't like it, *because*". I never vetoed the vloader, but I
always did say I did not like it. What's wrong with that exactly, is it
not allowed ? In this particular case, I think it allows too many
things, and will lead to less war portability, so actually advertising
it is a bad idea to me.
I'll be back next week for more community fun, Tomcat has always put the
"fun" back into dys*fun*ctional :), it's an honor to participate
I get more and more provocations from you, for example on the Servlet
expert group, where you could not resist alluding to this conflict in
your introduction.
As I said earlier, if you think I'm so bad, then you need to call a vote
to remove my commit privileges. You seem to like votes, so it should be
doable, hopefully :| I have the impression we're not going to get
anywhere until then.
I think things are quite simple and functional with proper prior
discussion. If you prefer to commit first and pretend to "talk" later,
then it's inevitably going to lead to dysfunction and latent never
ending conflicts. What did you expect exactly ? ...
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
