Wiki diffs

2007-09-21 Thread Mark Thomas
All, I think the wiki is probably the best place to start drafting a new set of commit guidelines to cover what branches we have (and what state they are in), what is RTC, what is CTR, etc. However, I didn't want to propose we use the wiki whilst we weren't getting wiki diffs on the dev list. I h

[Tomcat Wiki] Update of "JakartaTomcat" by markt

2007-09-21 Thread Apache Wiki
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The following page has been changed by markt: http://wiki.apache.org/tomcat/JakartaTomcat The comment on the change is: Link to the newer main Tomcat wiki page rather than the old one.

Test - please ignore

2007-09-21 Thread Mark Thomas
Wiki config test. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: Review model take 2

2007-09-21 Thread Jim Jagielski
On Sep 21, 2007, at 4:27 PM, Costin Manolache wrote: On 9/21/07, Jim Jagielski <[EMAIL PROTECTED]> wrote: Just propose a polite way to move from the commit for a controversial change ( i.e. when someone feels strongly it's going to the wrong direction, even if technically code is ok ) to

Re: Review model take 2

2007-09-21 Thread Costin Manolache
On 9/21/07, Jim Jagielski <[EMAIL PROTECTED]> wrote: > > > > Just propose a polite way to move from the commit for a controversial > > change ( i.e. when someone feels strongly it's going to the wrong > > direction, > > even > > if technically code is ok ) to the majority and 3+1 process - and > >

Re: Review model take 2

2007-09-21 Thread Jim Jagielski
On Sep 21, 2007, at 3:49 PM, Costin Manolache wrote: Certainly the rest of the community out there in addition to the PMC determines a lot of that. In which point, I think the majority would rule. Then I guess we are in agreement :-) woo hoo! Just propose a polite way to move from the

Re: Review model take 2

2007-09-21 Thread Costin Manolache
On 9/21/07, Jim Jagielski <[EMAIL PROTECTED]> wrote: > > > On Sep 21, 2007, at 3:10 PM, Costin Manolache wrote: > > > > > Let's assume CTR ( lazy consensus - i.e. assume everyone agrees ) - what > if it > > turns that the consensus is lacking, not on the technical validity of > the Certainly the

Re: Review model take 2

2007-09-21 Thread Jim Jagielski
On Sep 21, 2007, at 3:10 PM, Costin Manolache wrote: Let's assume CTR ( lazy consensus - i.e. assume everyone agrees ) - what if it turns that the consensus is lacking, not on the technical validity of the change but on weather a particular change is the right direction. Should tomcat

Re: Review model take 2

2007-09-21 Thread Costin Manolache
On 9/21/07, Jim Jagielski <[EMAIL PROTECTED]> wrote: > > > On Sep 21, 2007, at 1:23 PM, Costin Manolache wrote: > > There are 2 ways for code in trunk to get released: > >1. trunk, the whole kit and kaboodle becomes a release > branch. For this to happen, RTC comes in and the > PMC

Re: Review model take 2

2007-09-21 Thread Jim Jagielski
On Sep 21, 2007, at 2:46 PM, William A. Rowe, Jr. wrote: Jim Jagielski wrote: So how about this... this is something that has been done, and is being done, in just about every ASF project. Why don't we vote on this and give it a time-table at which point we review how it's worked out over the

Re: Review model take 2

2007-09-21 Thread William A. Rowe, Jr.
Jim Jagielski wrote: > > So how about this... this is something that has been done, and > is being done, in just about every ASF project. Why don't > we vote on this and give it a time-table at which point we > review how it's worked out over the last 3 months or so > and fine-tune if and as neede

svn commit: r578220 - /tomcat/sandbox/gdev6x/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java

2007-09-21 Thread fhanik
Author: fhanik Date: Fri Sep 21 11:26:51 2007 New Revision: 578220 URL: http://svn.apache.org/viewvc?rev=578220&view=rev Log: bz http://issues.apache.org/bugzilla/show_bug.cgi?id=43435 Modified: tomcat/sandbox/gdev6x/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java Modified:

DO NOT REPLY [Bug 43435] - AbstractReplicatedMap.memberDisappeared is executed more than the necessity.

2007-09-21 Thread bugzilla
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

svn commit: r578218 - in /tomcat/tc6.0.x/trunk: java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java webapps/docs/changelog.xml

2007-09-21 Thread fhanik
Author: fhanik Date: Fri Sep 21 11:26:31 2007 New Revision: 578218 URL: http://svn.apache.org/viewvc?rev=578218&view=rev Log: bz http://issues.apache.org/bugzilla/show_bug.cgi?id=43435 Modified: tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java tomcat/

Re: Review model take 2

2007-09-21 Thread Jim Jagielski
On Sep 21, 2007, at 2:13 PM, Jim Jagielski wrote: 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 other commit for which a commi

Re: Review model take 2

2007-09-21 Thread Filip Hanik - Dev Lists
Jim Jagielski wrote: On Sep 21, 2007, at 1:59 PM, Jim Jagielski wrote: All good points. It just seems to me that the voting should be on code that, as you said, affects people. When the code enters a release branch, then approval is needed. The fact that it's been in trunk and has worked well

Re: Review model take 2

2007-09-21 Thread Jim Jagielski
On Sep 21, 2007, at 1:59 PM, Jim Jagielski wrote: All good points. It just seems to me that the voting should be on code that, as you said, affects people. When the code enters a release branch, then approval is needed. The fact that it's been in trunk and has worked well and that others withi

Re: Review model take 2

2007-09-21 Thread Jim Jagielski
On Sep 21, 2007, at 1:23 PM, Costin Manolache wrote: I'm a bit confused - what happens with the trunk then ? Usually the trunk will become the new release - or the code from the trunk will somehow get released. There are 2 ways for code in trunk to get released: 1. trunk, the whole ki

Re: Review model take 2

2007-09-21 Thread Costin Manolache
On 9/21/07, Jim Jagielski <[EMAIL PROTECTED]> wrote: > > > On Sep 21, 2007, at 11:12 AM, Costin Manolache wrote: > > > I agree with the previous mail that for a while people will be > > careful to > > discuss and review - so probably we don't really need to do anything, > > this long thread may hav

Re: Review model take 2

2007-09-21 Thread Jim Jagielski
On Sep 21, 2007, at 11:12 AM, Costin Manolache wrote: I agree with the previous mail that for a while people will be careful to discuss and review - so probably we don't really need to do anything, this long thread may have raised enough awareness. Regarding release numbers - I also agree wi

Re: Review model take 2

2007-09-21 Thread Costin Manolache
I agree with the previous mail that for a while people will be careful to discuss and review - so probably we don't really need to do anything, this long thread may have raised enough awareness. Regarding release numbers - I also agree with you on such a scheme. My only concern with your last 2 e

Re: Review model take 2

2007-09-21 Thread Jim Jagielski
Posted on another list, but adding it here with some refinements: If I had my druthers I'd say we have all release branches created and set as RTC. We then follow a release number similar to httpd and others where even number minors are release, and odd numbers are development. We then have a rea

Re: Review model take 2

2007-09-21 Thread Jim Jagielski
On Sep 21, 2007, at 4:45 AM, Henri Gomez wrote: +1 RTC is a good idea for release and fixes. Let's make use of RTC for release and CTR for more experimental code. I agree. I think that no on can disagree that, more than anything else, right now, more people will be focused on patches, watc

Re: Review model take 2

2007-09-21 Thread Jim Jagielski
On Sep 21, 2007, at 4:07 AM, jean-frederic clere wrote: Filip Hanik - Dev Lists wrote: It could be a simple as (as opposed to trying to reinvent the apache way) 1. Through out a vote for the 6.0.x/5.5.x/5.0.x/4.1.x branches RTC or CTR Every one should why Sun had forked from Tomcat... I

DO NOT REPLY [Bug 29091] - Non-ascii characters are not handled correctly...

2007-09-21 Thread bugzilla
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 43444] - Class loading problem

2007-09-21 Thread bugzilla
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 43444] - Class loading problem

2007-09-21 Thread bugzilla
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 43444] New: - Class loading problem

2007-09-21 Thread bugzilla
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 43442] - mod_jk documentation modification

2007-09-21 Thread bugzilla
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 43442] New: - mod_jk documentation modification

2007-09-21 Thread bugzilla
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

2007-09-21 Thread Henri Gomez
+1 RTC is a good idea for release and fixes. Let's make use of RTC for release and CTR for more experimental code. 2007/9/21, jean-frederic clere <[EMAIL PROTECTED]>: > Filip Hanik - Dev Lists wrote: > > It could be a simple as (as opposed to trying to reinvent the apache way) > > > > 1. Throu

Re: Review model take 2

2007-09-21 Thread jean-frederic clere
Filip Hanik - Dev Lists wrote: > It could be a simple as (as opposed to trying to reinvent the apache way) > > 1. Through out a vote for the 6.0.x/5.5.x/5.0.x/4.1.x branches RTC or CTR Every one should why Sun had forked from Tomcat... I am sure a RTC on stable branches would have prevent it. No

Re: Review model take 2

2007-09-21 Thread jean-frederic clere
Henri Gomez wrote: > So what about RTC for core and CTR for extensions in incubator land ? Well see the result of the "[VOTE] Make released versions RTC". We need 2 things innovation (on a common trunk) and stability on released branches. That why I made the proposal "[VOTE] Make released versions