Remy Maucherat wrote:
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 ?
as I said earlier, do what you feel is right with trunk. My opinion
hasn't changed, and you keep twisting my views. but I'm out of the debate
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.
huh? it was a mere reference that we are working on the same project,
twist it anyway you want.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
