+1
Cheers
Jean-Frederic
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
programmatically
- any
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
programmatically
yes,
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
+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 ):
-
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 are accessible to the user
+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
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
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
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.
As much as
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=43423.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=43423.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=43423.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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 keep a
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
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 precise draft.
Patches which would go to review would
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 create
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
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 corresponding
Author: markt
Date: Wed Sep 19 22:06:56 2007
New Revision: 577553
URL: http://svn.apache.org/viewvc?rev=577553view=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:
19 matches
Mail list logo
