Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <46E001C2.70607@hanik.com>
Date: Thu, 06 Sep 2007 07:33:54 -0600
From: Filip Hanik - Dev Lists <devlists@hanik.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: [VOTE] Make released versions RTC
References: <46DD1CFD.80908@gmail.com>
 <FA97C969-28CF-44D6-BD9D-6529AADB801D@jaguNET.com>
 <46DD822C.8060807@apache.org> <46DDF831.7090506@hanik.com>
 <46DE7C27.7020202@apache.org>
 <DAE8E1AD-4CE9-426C-B26E-DD4A42FF9D8C@jaguNET.com>
 <46DEB18A.6050403@apache.org> <46DF6929.1080107@hanik.com>
 <46DFE379.90203@apache.org>
In-Reply-To: <46DFE379.90203@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>


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