Re: Review model take 2

jean-frederic clere wrote: Filip Hanik - Dev Lists wrote: Remy Maucherat wrote: Hi, Another more precise draft. Patches which would go to review would be: - API changing patches (any protected or above signature change) on APIs which are accessible to the user either from confirguration or pr

Re: Review model take 2

+1 I agree with Costin here. If it can't be added/removed as a pluggin, then it doesn't belong in the default Tomcat distro. "Costin Manolache" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > +1 > > I think one exception ( or maybe something that should be easily > fast-tracked )

Re: Review model take 2

Remy Maucherat wrote: > jean-frederic clere wrote: >> Filip Hanik - Dev Lists wrote: >>> Remy Maucherat wrote: Hi, Another more precise draft. Patches which would go to review would be: - API changing patches (any protected or above signature change) on APIs which

Re: Review model take 2

+1 as well. Seems we have come to some sort of conclusion. (At least the proposal holds the majority of votes) I'll left this tread for a day or two and then create an official proposal draft we can vote on. If thats accepted, I'll create needed documents like STATUS, ROADMAP containing that draf

Re: Review model take 2

jean-frederic clere wrote: Remy Maucherat wrote: jean-frederic clere wrote: Filip Hanik - Dev Lists wrote: Remy Maucherat wrote: Hi, Another more precise draft. Patches which would go to review would be: - API changing patches (any protected or above signature change

Re: Review model take 2

jean-frederic clere wrote: Well I see at least 3 reasons to revert it: - Prevent accidental inclusion in a release. - Allow a more easy testing and evaluation of a another patch that fixes the same thing. - Force the community to look for another solution. As much as possible, I would like to a

Re: Review model take 2

Remy Maucherat wrote: > jean-frederic clere wrote: >> Well I see at least 3 reasons to revert it: >> - Prevent accidental inclusion in a release. >> - Allow a more easy testing and evaluation of a another patch that fixes >> the same thing. >> - Force the community to look for another solution. >

DO NOT REPLY [Bug 43423] - catalina.sh -force too fast

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 43423] - catalina.sh -force too fast

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 43423] - catalina.sh -force too fast

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: Review model take 2

jean-frederic clere wrote: > > Now for me that just makes another chapter in the "STATUS" file: > "PATCHES being discussed". After a week those patches should be accepted > or reverted. Reverted patches and corresponding discussions should stay > in the "STATUS" until a solution is found. I would

Re: Review model take 2

I agree that a simple majority should be enough for any API change or any feature, but I don't think this was the spirit of the proposal. What I see as a problem is not involving the community in the decision making about basic features. Let's make it clear - adding new features or replacing/impr

Re: Review model take 2

"Filip Hanik - Dev Lists" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > jean-frederic clere wrote: >> Remy Maucherat wrote: >> >>> jean-frederic clere wrote: >>> Filip Hanik - Dev Lists wrote: > Remy Maucherat wrote: > >> Hi, >> >> Another more precis

Re: Review model take 2

Costin Manolache wrote: > > What I see as a problem is not involving the community in the decision > making about basic features. > > Let's make it clear - adding new features or replacing/improving any > component in tomcat > should stay CTR and should be encouraged and supported. Anyone can cre

Re: Review model take 2

Bill Barker wrote: > > Remy was being really nice to the community by not requiring a vetoed patch > to be withdrawn. Personally, I would go with j-f-c's position, and withdraw > a vetoed patch immediately (and have done so on several occations, even when > I got to re-apply it after enough di

Re: Review model take 2

"William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > jean-frederic clere wrote: >> >> Now for me that just makes another chapter in the "STATUS" file: >> "PATCHES being discussed". After a week those patches should be accepted >> or reverted. Reverted patches and c

svn commit: r577553 - in /tomcat/site/trunk: docs/index.html xdocs/index.xml

Author: markt Date: Wed Sep 19 22:06:56 2007 New Revision: 577553 URL: http://svn.apache.org/viewvc?rev=577553&view=rev Log: Update latest 5.5.x version Modified: tomcat/site/trunk/docs/index.html tomcat/site/trunk/xdocs/index.xml Modified: tomcat/site/trunk/docs/index.html URL: http://

Re: Review model take 2

"William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Bill Barker wrote: >> >> Remy was being really nice to the community by not requiring a vetoed >> patch >> to be withdrawn. Personally, I would go with j-f-c's position, and >> withdraw >> a vetoed patch immed

Re: Review model take 2

William A. Rowe, Jr. wrote: jean-frederic clere wrote: Now for me that just makes another chapter in the "STATUS" file: "PATCHES being discussed". After a week those patches should be accepted or reverted. Reverted patches and corresponding discussions should stay in the "STATUS" until a solutio