Re: Review model take 2

[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 RTC".

CTR didn't seem to work on the "old" trunk and we have to prevent this
happening again, therefore comes the idea of a "RTC on demand".

Cheers

Jean-Frederic

> 
> 2007/9/21, Costin Manolache <[EMAIL PROTECTED]>:
>> I have a strong feeling this is turning again into a debate over words,
>> arcane details
>> and abstract concepts ( 'what is a trunk' and how to increase innovation )
>>
>> The real issue is quite simple, and not having a trunk or all the new
>> process seems
>> more like an attempt to solve it:
>>
>> We want tomcat evolution to be done by consensus or at least majority, not
>> by one
>> individual ( be it Remy or Filip or anyone else ) making decisions and
>> changes to the core API without
>> consultation and agreement from others ( and yes, most vetoes are probably
>> invalid and
>> bad - the changes are technically ok, and the veto is a blunt tool to
>> express lack of consensus
>> and frustration ).
>>
>> The whole veto / remove trunk / personal hurt feelings / CTR / RTC / process
>> debate
>> is just a way to avoid this from happening.
>>
>> Yes, we want innovation and change and contributions and all that - but that
>> doesn't mean
>> that anyone who can make a technically valid change ( i.e. where a veto
>> would be invalid )
>> should make it - if it affects other people and it lacks consensus.
>>
>> That doesn't mean you can't add features ( to 6.0 or trunk or however you
>> want to call it ), or you
>> can't make big changes, or someone can block 'progress' or impose his own
>> vision of progress.
>> All those proposals evolve around how to involve more people in decision
>> making and be as close
>> to consensus as possible.
>>
>> I personally consider tomcat way overbloated - so I think I'm on the same
>> side with Remy on voting against
>> adding any new feature that could be done as a plugin, and I would be happy
>> to see 'innovations'
>> in tomcat removed from std and moved to separate plugins, until we're at the
>> same size with jetty
>> or other containers in the base distro. But I do understand Filip's
>> frustration and the desire to try now
>> things - and this should happen, not in sandbox but in 6.0  tree, except not
>> in the core and with
>> controlled API changes.
>>
>>
>> Costin
>>
>> On 9/20/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
>>> Will f/w board since this follows from the 'no more trunk' comment which
>>> some officers questioned.  Please don't cc per-say, but feel free to f/w
>>> a relevant response to [EMAIL PROTECTED] (it's bad form to crosspost a 
>>> message
>>> with both public-and-private destinations).
>>>
>>> Bill Barker wrote:
 "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote in message
> All that said, the topic of "no more trunk" came up at the board
>>> meeting
> today.  I gave a very brief background and suggested that some of the
> renewed interest by folks who had been silent throughout the Filip-Remy
> trunk war is a hopeful sign; with renewed interest the project is very
> likely to be able to manage itself successfully through these personal
> and stylistic disagreements; the board is satisfied to see the project
> try to work out these issues themselves as long as development once
>>> again
> is encouraged.
 TC 4.1.x and TC 5.5.x represented major changes to the core API, and
 resulted in much more stable Tomcat code.  There is no such issue for TC
 6.0.x (just a disagreement on the comet API, which we have already dealt
 with, and decided to let software-darwinism take it's course).  Thus,
>>> there
 is really no reason for a "trunk" at this time, at least until the
>>> Servlet
 3.0 spec comes out.  If somebody wanted to make a [PROPOSAL] for major
 changes to the core TC 6.0.x API, then I can see setting up a "trunk"
>>> again.
 But there is no such animal lurking at this time.
>>> No doubt, these were significant departures from their previous code.
>>>
>>> But, are you suggesting that there is no need for trunk until there is an
>>> idea you happen to champion?  Present you with an idea that you like and
>>> half the committee might decide to permit new development again?
>>>
>>> This is certainly turning the idea of "show me the code" on it's head.
>>>
>>> To give an example oft cited on this list, httpd maintains a trunk.  It
>>> might be released some day as-is, it might never be released.  But it's
>>> a staging ground to prove up an idea before injecting that idea into the
>>> shipping stable version.  It appears there is no such wilderness at
>>> Tomcat.
>>>
>>> Sandboxes don't cut it.  It's very clear sandboxes are one-man-shows at
>>> Tomcat.  As s

Re: Review model take 2

[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.

None needs a toy for production.
Why do you think Apache httpd is still the best open source WEB server
(see http://www.infoworld.com/slideshow/2007/09/114-best_of_open_so-5.html)?
- Because stable branches are really stable why are they so stable
because they use RTC.

> 2. We'll all pay more attention to discussing a change prior to SVN
> commit whether it is RTC or CTR
>   But we don't need a "new process" for this

That is not a new process what we need is to define what to do if the
consensus doesn't come out when the review ended in "please stop we need
to discuss that commit/feature/fix".


> 3. Bring back trunk as CTR, again, following the advice in step 2 (yes,
> me included)

yes we need a place for common innovation.

> 
> And have it all over with. The reason I'm opposing here is that the
> tomcat community is trying to (re)invent a new development process.
> Trust me, if there was a better way, someone else would have probably
> thought of it, it's not like we are the originators and demi gods of
> programming.
> The reason we are at the ASF, is to piggy back on the ASF ways, as
> simple as that.

Again something worked wrong you can say it is your fault (and tell it
to everyone (including Remy)) but nothing prevents that happening again.
 Should we define a process to prevent that? For me yes.

Cheers

Jean-frederic

> 
> Filip
> 
> 
> 
> jkew wrote:
>> Folks,
>>
>> I'm somewhat on the outside looking here, so I'm probably going to be
>> a little naive:
>>
>> 1. It's really time to come to a conclusion on this, before people get
>> too exhausted and give up.
>> 2. Ideally everyone should compromise a little on a solution, but this
>> doesn't always happen.
>> 3. People really hate making decisions that are going to be set in
>> stone, especially when they are emotionally involved.
>>
>> What about a trial period of three(or 'n') months for a review model?
>> People who hate the review model may be more willing to compromise a
>> bit more for a 'test' phase. The review model does not have to be set
>> in stone, but we do need something in place until people can calm down.
>>
>> 1. Those who compromise more than others should be willing to give the
>> new system an n month trial period to allow a new process a chance to
>> settle w/o constant criticism.
>> 2. Those who compromised less should be willing to change the system
>> after the n month trial period.
>>
>> Whether it is Remy's plan or another, it is really important to codify
>> some process at this point. I would rather not waste any more bits on
>> this. I hate the idea of proposing anything at all in the middle of
>> this discussion, but we have got to get past this.
>>
>> -John
>>
>> 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 other commit for which a committer asks for the RTC procedure
>>> should be rollbacked if it hinders concurrent work or is to be
>>> included in a release tag, and go through the RTC procedure
>>>
>>> The RTC procedure would include a STATUS file in the Tomcat svn
>>> listing all pending "up to review" changes. A successful vote with a
>>> +3 margin is required. A patch can remain under review for as long as
>>> the committer wishes, and it should be allowed to freely "advertise"
>>> and discuss the vote.
>>>
>>> The idea would be to force a consensus for commits which could have
>>> significant implications, and help stage technical discussions
>>> (rather than discussions about the validity of the disagreement). It
>>> would introduce a small delay for committing certain patches and a
>>> minor slowdown for development pace in theory, but in practice I've
>>> noticed conflicts waste a lot more time.
>>>
>>> This would also mean it is possible to make a change that a number of
>>> committers oppose (possibly, would veto) if enough committers are in
>>> favor of it.
>>>
>>> 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]
>>
>>
>>
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


---

Re: Review model take 2

[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. 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.
>
> None needs a toy for production.
> Why do you think Apache httpd is still the best open source WEB server
> (see http://www.infoworld.com/slideshow/2007/09/114-best_of_open_so-5.html)?
> - Because stable branches are really stable why are they so stable
> because they use RTC.
>
> > 2. We'll all pay more attention to discussing a change prior to SVN
> > commit whether it is RTC or CTR
> >   But we don't need a "new process" for this
>
> That is not a new process what we need is to define what to do if the
> consensus doesn't come out when the review ended in "please stop we need
> to discuss that commit/feature/fix".
>
>
> > 3. Bring back trunk as CTR, again, following the advice in step 2 (yes,
> > me included)
>
> yes we need a place for common innovation.
>
> >
> > And have it all over with. The reason I'm opposing here is that the
> > tomcat community is trying to (re)invent a new development process.
> > Trust me, if there was a better way, someone else would have probably
> > thought of it, it's not like we are the originators and demi gods of
> > programming.
> > The reason we are at the ASF, is to piggy back on the ASF ways, as
> > simple as that.
>
> Again something worked wrong you can say it is your fault (and tell it
> to everyone (including Remy)) but nothing prevents that happening again.
>  Should we define a process to prevent that? For me yes.
>
> Cheers
>
> Jean-frederic
>
> >
> > Filip
> >
> >
> >
> > jkew wrote:
> >> Folks,
> >>
> >> I'm somewhat on the outside looking here, so I'm probably going to be
> >> a little naive:
> >>
> >> 1. It's really time to come to a conclusion on this, before people get
> >> too exhausted and give up.
> >> 2. Ideally everyone should compromise a little on a solution, but this
> >> doesn't always happen.
> >> 3. People really hate making decisions that are going to be set in
> >> stone, especially when they are emotionally involved.
> >>
> >> What about a trial period of three(or 'n') months for a review model?
> >> People who hate the review model may be more willing to compromise a
> >> bit more for a 'test' phase. The review model does not have to be set
> >> in stone, but we do need something in place until people can calm down.
> >>
> >> 1. Those who compromise more than others should be willing to give the
> >> new system an n month trial period to allow a new process a chance to
> >> settle w/o constant criticism.
> >> 2. Those who compromised less should be willing to change the system
> >> after the n month trial period.
> >>
> >> Whether it is Remy's plan or another, it is really important to codify
> >> some process at this point. I would rather not waste any more bits on
> >> this. I hate the idea of proposing anything at all in the middle of
> >> this discussion, but we have got to get past this.
> >>
> >> -John
> >>
> >> 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 other commit for which a committer asks for the RTC procedure
> >>> should be rollbacked if it hinders concurrent work or is to be
> >>> included in a release tag, and go through the RTC procedure
> >>>
> >>> The RTC procedure would include a STATUS file in the Tomcat svn
> >>> listing all pending "up to review" changes. A successful vote with a
> >>> +3 margin is required. A patch can remain under review for as long as
> >>> the committer wishes, and it should be allowed to freely "advertise"
> >>> and discuss the vote.
> >>>
> >>> The idea would be to force a consensus for commits which could have
> >>> significant implications, and help stage technical discussions
> >>> (rather than discussions about the validity of the disagreement). It
> >>> would introduce a small delay for committing certain patches and a
> >>> minor slowdown for development pace in theory, but in practice I've
> >>> noticed conflicts waste a lot more time.
> >>>
> >>> This would also mean it is possible to make a change that a number of
> >>> committers oppose (possibly, would veto) if enough committers are in
> >>> favor of it.
> >>>
> >>> Rémy
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>> For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>
> >>
> >> 

DO NOT REPLY [Bug 43442] New: - mod_jk documentation modification

[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_bug.cgi?id=43442

   Summary: mod_jk documentation modification
   Product: Tomcat 5
   Version: Unknown
  Platform: Other
OS/Version: All
Status: NEW
  Severity: trivial
  Priority: P2
 Component: Connector:AJP
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


A few small grammatical changes.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43442] - mod_jk documentation modification

[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_bug.cgi?id=43442





--- Additional Comments From [EMAIL PROTECTED]  2007-09-21 03:17 ---
Created an attachment (id=20863)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20863&action=view)
xdocs\reference\workers.diff

Small test modification of 
http://svn.apache.org/repos/asf/tomcat/connectors/trunk/jk/xdocs/reference/workers.xml

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43444] New: - Class loading problem

[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_bug.cgi?id=43444

   Summary: Class loading problem
   Product: Tomcat 6
   Version: 6.0.14
  Platform: PC
OS/Version: Windows Vista
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When deploying a webapp contain some TLDs and containing custom JAXP stuff, 
the web app is not completely removed when undeploying.

The problem is that org.apache.catalina.startup.TldConfig has a static member 
tldDigester which uses a SAXParser. In my case a parser from the web app is 
being used. So since the parser (its class is loaded with the 
WebAppClassLoader) will be referenced from the TldConfig class (which is 
loaded with the StandardClassLoader) the web app class loader never gets 
collected which leads to a full permspace after a few redeploys.

How to reproduce:
Create a WAR containing an empty web.xml and jstl-1.1.2.jar, standard-
1.1.2.jar (both from Jakarta Taglibs project), xercesImpl-2.9.0.jar and xml-
apis-2.9.0.jar (both from Xerces project). Run a tomcat containing just the 
manager web app. Deploy the WAR. Undeploy the WAR. Take a heap dump (e.g. 
using jmap). Analyse the dump (e.g. using jhat). Browse to the class of 
org.apache.catalina.startup.TldConfig. See that it is being loaded by the 
StandardClassLoader. Browse to the object pointed to by the tldDigester static 
member. Jump to the object pointed to by the parser instance member. In this 
example it is an org.apache.xerces.jaxp.SAXParserImpl. Jump the class of this 
object. See that it is being loaded by the WebAppClassLoader. This is why the 
WebAppClassloader will never be collected.

I am using JDK 1.6.0_02.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43444] - Class loading problem

[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_bug.cgi?id=43444





--- Additional Comments From [EMAIL PROTECTED]  2007-09-21 04:55 ---
Sorry, but I can not attach the WAR described above since I can not compress 
it to be smaller than 1000kb.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43444] - Class loading problem

[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_bug.cgi?id=43444





--- Additional Comments From [EMAIL PROTECTED]  2007-09-21 05:19 ---
An easy fix would be to make the tldDigester member in TldConfig not static. 
This would cost some extra cycles when deploying applications, but that would 
be OK for me if it fixes a memory leak.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[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_bug.cgi?id=29091


[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|other   |Windows XP
Version|5.0.24  |5.5.24




--- Additional Comments From [EMAIL PROTECTED]  2007-09-21 06:19 ---
By following the instructions here, I am able to verify that create, edit and 
delete all work for the non-ASCII charactor username. However I can not log 
into web admin app by using the non-ASCII(Chinese in this case) username. I 
received the invalid username/password error. I think there might be something 
wrong with the j_security_check. This is a bigger problem because I have to 
restrict username to be ASCII in my own app. I am using Tomcat 5.5.25.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Review model take 2

[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, watching over people's shoulders and *communicating*
issues/concerns/problems with patches and development than
most likely ever before.

So why not *use* that... when the above is the case, then
CTR and RTC and "normal" ASF communal development works...


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Review model take 2

[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 am sure a RTC on
stable branches would have prevent it.



It's no secret that another reason was the Sun could no
longer tolerate some of the personalities within TC.

I stress again that for years and years, TC has not been
seen as a happy, welcoming place to be. It's just that
things have reached a head at this point.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Review model take 2

[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 real trunk, using whatever bits and pieces
of what we currently have and call that TC 6.3 (thus
allowing for a 6.2 being created from it if so deemed).
This also allows for patches/code/features to be
applied in 6.3 and proposed for backport to 6.0
(again, ala httpd and others). 6.3/6.2 also serves as
the community testbed for not only new features but
a plugin/module architecture.

This can be refined by bumping up to 6.5/6.4 for the
more future reaching stuff and allowing for a 6.3/6.2 for
some feature of the old trunk that external projects
were using/depending on...

Trunk, of course, would be CTR. Backports and release
branches would be RTC. Development branches (the odd numbered
ones) would be CTR.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Review model take 2

[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 emails: it doesn't address the root
problem,
what kind of decision-making should be done in the 6.3/6.5/trunk/dev branch,
on API changes and core features ( i.e. things that will indirectly affect
other people ) ?

It is clear that the previous model doesn't work - any developer submitting
code ( usually valid ),
and then fighting over why a veto is invalid. We do need a way to have core
changes
reviewed by more people and be sure we have a fight-free, polite mode of
expressing 'I don't
think we should do this in the core, please try a different approach - maybe
a plugin, or
a new connector, etc' - without arguing about the actual change itself, just
about the direction
we want for the project. And this should involve more than 2 opinions.

I still think the proposal to do CTR, assuming consensus exists, but on any
sign of disagreement on
a change affecting the 'core' - fall back to RTC ( or request a simple vote,
3+1 and more + than - on
the _goals_, instead of the implementation ). This should also be done
before including new big features
to be bundled in the next release.

Costin

On 9/21/07, Jim Jagielski <[EMAIL PROTECTED]> wrote:
>
> 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 real trunk, using whatever bits and pieces
> of what we currently have and call that TC 6.3 (thus
> allowing for a 6.2 being created from it if so deemed).
> This also allows for patches/code/features to be
> applied in 6.3 and proposed for backport to 6.0
> (again, ala httpd and others). 6.3/6.2 also serves as
> the community testbed for not only new features but
> a plugin/module architecture.
>
> This can be refined by bumping up to 6.5/6.4 for the
> more future reaching stuff and allowing for a 6.3/6.2 for
> some feature of the old trunk that external projects
> were using/depending on...
>
> Trunk, of course, would be CTR. Backports and release
> branches would be RTC. Development branches (the odd numbered
> ones) would be CTR.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Review model take 2

[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 with you on such a scheme.

My only concern with your last 2 emails: it doesn't address the root
problem,
what kind of decision-making should be done in the 6.3/6.5/trunk/ 
dev branch,
on API changes and core features ( i.e. things that will indirectly  
affect

other people ) ?

It is clear that the previous model doesn't work - any developer  
submitting

code ( usually valid ),
and then fighting over why a veto is invalid. We do need a way to  
have core

changes
reviewed by more people and be sure we have a fight-free, polite  
mode of

expressing 'I don't
think we should do this in the core, please try a different  
approach - maybe

a plugin, or
a new connector, etc' - without arguing about the actual change  
itself, just

about the direction
we want for the project. And this should involve more than 2 opinions.

I still think the proposal to do CTR, assuming consensus exists,  
but on any

sign of disagreement on
a change affecting the 'core' - fall back to RTC ( or request a  
simple vote,

3+1 and more + than - on
the _goals_, instead of the implementation ). This should also be done
before including new big features
to be bundled in the next release.



But anything that *reaches* a release branch is ALWAYS RTC. So,
by design and definition, anything that affects other people,
does so because it is part of a release branch and therefore,
since it is part of the release branch, got in there via RTC.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Review model take 2

[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 have raised enough awareness.
> >
> > Regarding release numbers - I also agree with you on such a scheme.
> >
> > My only concern with your last 2 emails: it doesn't address the root
> > problem,
> > what kind of decision-making should be done in the 6.3/6.5/trunk/
> > dev branch,
> > on API changes and core features ( i.e. things that will indirectly
> > affect
> > other people ) ?
> >
> > It is clear that the previous model doesn't work - any developer
> > submitting
> > code ( usually valid ),
> > and then fighting over why a veto is invalid. We do need a way to
> > have core
> > changes
> > reviewed by more people and be sure we have a fight-free, polite
> > mode of
> > expressing 'I don't
> > think we should do this in the core, please try a different
> > approach - maybe
> > a plugin, or
> > a new connector, etc' - without arguing about the actual change
> > itself, just
> > about the direction
> > we want for the project. And this should involve more than 2 opinions.
> >
> > I still think the proposal to do CTR, assuming consensus exists,
> > but on any
> > sign of disagreement on
> > a change affecting the 'core' - fall back to RTC ( or request a
> > simple vote,
> > 3+1 and more + than - on
> > the _goals_, instead of the implementation ). This should also be done
> > before including new big features
> > to be bundled in the next release.
> >
>
> But anything that *reaches* a release branch is ALWAYS RTC. So,
> by design and definition, anything that affects other people,
> does so because it is part of a release branch and therefore,
> since it is part of the release branch, got in there via RTC.



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.

But forget the release/trunk details - the question is how to determine the
goals or direction - things like should use switch coyote to nio, should we
change the API in one way or another, how much backward compatibility to
preserve, what to deprecate and what to bundle by default. Doesn't matter
where
it happens - the reason we have this conversation is because this kind of
decision was made by one or 2 people fighting each other and without
enough consensus - instead of the broader community.

Both Remy and Filip ( and quite a few other people actually ) are quick to
express their disapproval for something or their goals - and maybe sometimes
too blunt
and personal.

The proposed processes ( with their evident flaws ) are intended
to make it clear that neither of us 'decides' ( by veto or by sumitting
something ) -
either we have a consensus ( everyone agrees ), or at least the typical 3
+1  and
majority.

Costin

Re: Review model take 2

[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 kit and kaboodle becomes a release
 branch. For this to happen, RTC comes in and the
 PMC and dev community agree that trunk should serve
 as the basis for TC X.Y.

  2. Parts of trunk end up in releases. For this
 to happen a patch is proposed for backport to
 a release branch under RTC rules. Normally, this is
 noted and voted on in a STATUS file.

trunk continues to be operated under CTR, but all code *from*
trunk that goes into a release branch is via RTC.

But forget the release/trunk details - the question is how to  
determine the
goals or direction - things like should use switch coyote to nio,  
should we
change the API in one way or another, how much backward  
compatibility to
preserve, what to deprecate and what to bundle by default. Doesn't  
matter

where
it happens - the reason we have this conversation is because this  
kind of

decision was made by one or 2 people fighting each other and without
enough consensus - instead of the broader community.

Both Remy and Filip ( and quite a few other people actually ) are  
quick to
express their disapproval for something or their goals - and maybe  
sometimes

too blunt
and personal.

The proposed processes ( with their evident flaws ) are intended
to make it clear that neither of us 'decides' ( by veto or by  
sumitting

something ) -
either we have a consensus ( everyone agrees ), or at least the  
typical 3

+1  and
majority.


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 within
the PMC and dev community have played and worked with it
will count for something, but it is still a RTC rule. Having
trunk means we get consensus twice: the 1st under CTR (a lazy
consensus to be sure) and then when moved to release under
RTC.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Review model take 2

[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 within
the PMC and dev community have played and worked with it
will count for something, but it is still a RTC rule. Having
trunk means we get consensus twice: the 1st under CTR (a lazy
consensus to be sure) and then when moved to release under
RTC.



And again, what we are talking about is not that much
different from Remy's proposal:

Remy's proposal is:

  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 committer asks for the RTC  
procedure should be rollbacked if it hinders concurrent work or is to  
be included in a release tag, and go through the RTC procedure


  The RTC procedure would include a STATUS file in the Tomcat svn  
listing all pending "up to review" changes. A successful vote with a  
+3 margin is required. A patch can remain under review for as long as  
the committer wishes, and it should be allowed to freely "advertise"  
and discuss the vote.


If we simply say this is for release branches (X.Y where Y is even) then
we pretty much just have RTC, since simple patches will get the required
3 +1 votes pretty quickly). In fact, Remy's comment "to be included
in a release tag" pretty much makes it clear that what is the
concern is what is released (the "affects other people" rule).

If we have a trunk which is CTR, then we can also have a general rule
that says "For API changes, patches should be done with advance
notice under lazy consensus" ("I plan on doing this which will
break/improve/modify the API. I plan on committing this in 3 days.
Holler if you have any complaints")... which is a normal
courtesy anyway. For really far reaching ones, people break
off a sandbox, do their stuff there, and refer to the sandbox
repo directory when giving the advance notice... (this is
also good since it allows people to see the history behind
the development as well).

So I really don't see a lot of difference here...



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Review model take 2

[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 and that others within
the PMC and dev community have played and worked with it
will count for something, but it is still a RTC rule. Having
trunk means we get consensus twice: the 1st under CTR (a lazy
consensus to be sure) and then when moved to release under
RTC.



And again, what we are talking about is not that much
different from Remy's proposal:

Remy's proposal is:

  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 committer asks for the RTC procedure 
should be rollbacked if it hinders concurrent work or is to be 
included in a release tag, and go through the RTC procedure


  The RTC procedure would include a STATUS file in the Tomcat svn 
listing all pending "up to review" changes. A successful vote with a 
+3 margin is required. A patch can remain under review for as long as 
the committer wishes, and it should be allowed to freely "advertise" 
and discuss the vote.


If we simply say this is for release branches (X.Y where Y is even) then
we pretty much just have RTC, since simple patches will get the required
3 +1 votes pretty quickly). In fact, Remy's comment "to be included
in a release tag" pretty much makes it clear that what is the
concern is what is released (the "affects other people" rule).

If we have a trunk which is CTR, then we can also have a general rule
that says "For API changes, patches should be done with advance
notice under lazy consensus" ("I plan on doing this which will
break/improve/modify the API. I plan on committing this in 3 days.
Holler if you have any complaints")... which is a normal
courtesy anyway. For really far reaching ones, people break
off a sandbox, do their stuff there, and refer to the sandbox
repo directory when giving the advance notice... (this is
also good since it allows people to see the history behind
the development as well).

So I really don't see a lot of difference here...
This is what I have been trying to convey, although, much of my things 
get lost in the flame debate, mostly my fault.


the difference is in the eye of the beholder, that is why I believe 
going with the predefined rules that ASF already has, since going away 
from that leaves too much to interpretation, and it also makes it easier 
bringing in new committers, especially if they are already familiar with 
the ASF.


Filip




-
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]

Re: Review model take 2

[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 committer asks for the RTC  
procedure should be rollbacked if it hinders concurrent work or is  
to be included in a release tag, and go through the RTC procedure


  The RTC procedure would include a STATUS file in the Tomcat svn  
listing all pending "up to review" changes. A successful vote with  
a +3 margin is required. A patch can remain under review for as  
long as the committer wishes, and it should be allowed to freely  
"advertise" and discuss the vote.


If we simply say this is for release branches (X.Y where Y is even)  
then
we pretty much just have RTC, since simple patches will get the  
required

3 +1 votes pretty quickly. In fact, Remy's comment "to be included
in a release tag" pretty much makes it clear that what is the
concern is what is released (the "affects other people" rule).

If we have a trunk which is CTR, then we can also have a general rule
that says "For API changes, patches should be done with advance
notice under lazy consensus" ("I plan on doing this which will
break/improve/modify the API. I plan on committing this in 3 days.
Holler if you have any complaints")... which is a normal
courtesy anyway. For really far reaching ones, people break
off a sandbox, do their stuff there, and refer to the sandbox
repo directory when giving the advance notice... (this is
also good since it allows people to see the history behind
the development as well).



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 needed?

Once we agree this is a workable implementation, we can
determine numbering aspects and initial code repo loads.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[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/tc6.0.x/trunk/webapps/docs/changelog.xml

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java?rev=578218&r1=578217&r2=578218&view=diff
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
 (original)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
 Fri Sep 21 11:26:31 2007
@@ -713,6 +713,10 @@
 boolean removed = false;
 synchronized (mapMembers) {
 removed = (mapMembers.remove(member) != null );
+if (!removed) {
+if (log.isDebugEnabled()) log.debug("Member["+member+"] 
disappeared, but was not present in the map.");
+return; //the member was not part of our map.
+}
 }
 
 Iterator i = super.entrySet().iterator();

Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml?rev=578218&r1=578217&r2=578218&view=diff
==
--- tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Fri Sep 21 11:26:31 2007
@@ -36,6 +36,9 @@
   
 
   
+43435: Don't iterate and relocate sessions if they are not 
part of the map.
+  
+  
 43356: Keystore parameter is relative to CATALINA_BASE,
 Truststore is either defined as parameter, javax.net.ssl.trustStore or 
if empty
 defaults to the keystore.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[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_bug.cgi?id=43435


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-09-21 11:26 ---
Fixed.
Since memberDisappeared is called when any member goes away, not just map 
members.
If you see scenarios where the memberDisappeared is called multiple times with
the same member, please let me know, as that should not happen

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[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: 
tomcat/sandbox/gdev6x/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
URL: 
http://svn.apache.org/viewvc/tomcat/sandbox/gdev6x/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java?rev=578220&r1=578219&r2=578220&view=diff
==
--- 
tomcat/sandbox/gdev6x/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
 (original)
+++ 
tomcat/sandbox/gdev6x/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
 Fri Sep 21 11:26:51 2007
@@ -713,6 +713,10 @@
 boolean removed = false;
 synchronized (mapMembers) {
 removed = (mapMembers.remove(member) != null );
+if (!removed) {
+if (log.isDebugEnabled()) log.debug("Member["+member+"] 
disappeared, but was not present in the map.");
+return; //the member was not part of our map.
+}
 }
 
 Iterator i = super.entrySet().iterator();



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Review model take 2

[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 needed?
> 
> Once we agree this is a workable implementation, we can
> determine numbering aspects and initial code repo loads.

There's a confusing aspect; what if the new proposed process/policies
get dropping to a /dev/howitworks.html sort of document, and that
entire document is voted on?

It sounds (for the most part) that concensus is emerging anyways, so
it shouldn't be hard to start writing it down, and limiting discussion
to a couple of sentences of that doc that people want to discuss.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Review model take 2

[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 last 3 months or so
and fine-tune if and as needed?

Once we agree this is a workable implementation, we can
determine numbering aspects and initial code repo loads.


There's a confusing aspect; what if the new proposed process/policies
get dropping to a /dev/howitworks.html sort of document, and that
entire document is voted on?



My point is that its not really new, but rather based
on what other projects are doing. The only "new" part
would be the requirement that API changes require advanced
notice and, by default, are lazy consensus. Of course
this would be for trunk, since API changes on release
branches would be normal RTC rules anyway...

http://www.apache.org/foundation/voting.html

Trunk and development branches are just SVN best practices.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Review model take 2

[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 and dev community agree that trunk should serve
>   as the basis for TC X.Y.


Ok, but what is the decision process about what goes into the
trunk, in case changes lack consensus ?

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
bundle the
CGI / SSI support - or have a smaller set of feature in the base, like jetty
? NIO or apr ?
Keep backward compat or fix major problems - and what's the middle line ?

Current process seems to be 'everyone throws whatever in the trunk - as long
as nobody
can find a valid technicality for a veto, at the end the community takes the
whole things
and agrees/disagrees'. I.e. what we had so far, leading to lots of
frustration on both
sides. And if 2 people have different opinion on an API in the trunck -
first to make the change
that can't be vetoed, or gives up in the flame war -  wins.

API and big, long term changes and the direction of the project shouldn't
be  lazy consensus,
no matter if done in trunk or branch, i.e. result of one individual
submitting (valid) code.
It needs some more comunity involvment.


Costin

Re: Review model take 2

[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

bundle the
CGI / SSI support - or have a smaller set of feature in the base,  
like jetty

? NIO or apr ?
Keep backward compat or fix major problems - and what's the middle  
line ?




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.

sides. And if 2 people have different opinion on an API in the  
trunck -

first to make the change
that can't be vetoed, or gives up in the flame war -  wins.



Again, majority would rule.

All this is certainly not unique in any way to Tomcat.
Does anyone really think that developers in every other
ASF project, or any other project, don't have disagreements
or differing views of direction or implementation??
But this is about *collaborative, communal* development.
If unanimous consensus can't be reached, then majority
rules and we go on from there.

All this requires an active and attentive developer community
that makes up its own mind... I don't think anyone can argue that
we don't have that now :)

API and big, long term changes and the direction of the project  
shouldn't

be  lazy consensus,
no matter if done in trunk or branch, i.e. result of one individual
submitting (valid) code.
It needs some more comunity involvment.


No one has said that at all, afaik. So I agree with your
strawman argument :)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Review model take 2

[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 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 :-)

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 we're
done.

As you know - some people are complaining that veto is abused ( and that's
right ),
many Rs turn into flame wars and get personal - so the issue is how to avoid

a technical code discussion for a non-technical or subjective issue.


Costin

Re: Review model take 2

[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 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  
we're

done.

As you know - some people are complaining that veto is abused ( and  
that's

right ),
many Rs turn into flame wars and get personal - so the issue is how  
to avoid


a technical code discussion for a non-technical or subjective issue.



First, it's important to recall that whether under CTR or RTC,
there is always Review. If people, after something has
been committed under CTR has issues with it, then
that is Reviewing it after all. We already discussed
technical voting, but what about "direction" or "vision"
review. Or, as you said in a previous Email:


... a polite way of  saying:

"Hey, nothing wrong with the code itself, but I don't think there  
is enough

support from
the community for the direction you're going - could you confirm  
that a

majority and
at least 3 people think it fits our goals ?"




That's still part of the review process... Vetoes are
there to prevent code from being committed, but not
all reviews are for the functional aspects of the
actual code but rather to determine how much support
there is for an implementation or feature... So I would
say that this is still a valid and expected part
of the R in *both* CTR and RTC.

The thing is, of course, one cannot veto code based
on non-technical reasons, but one can certainly review
it based on such reasons and ask for some guidance that
it makes sense. IMO, most of those types of cases
should fall into the following types:

  1. People who agree and will help support it,
 implement it, etc... (+1)
  2. People who don't care one way or another. (+0)
  3. People who don't like it, but hey, if it helps
 you out and there are other people behind it,
 I won't stand in your way. (-0.9)
  4. I don't like it and this is why. It would be
 a mistake. (-1)

So when voting, one would count up the number of +1s and -1s
and see who wins. The proposal can be changed to address
deficiencies and another vote called if need be, after all
we want to achieve more universal consensus. Some places
say "As long as you have 3 people behind this, then go
for it", which implies most people are therefore in the
+0 or -0.9 and no one feels so strongly about it that
they vote a -1. But again, the -1 is not a veto per se,
since it's not technical merit being discussed or
voted on, but rather community support.

Again, the ASF voting rules kind of address this already...



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Review model take 2

[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
> > we're
> > done.
> >
> > As you know - some people are complaining that veto is abused ( and
> > that's
> > right ),
> > many Rs turn into flame wars and get personal - so the issue is how
> > to avoid
> >
> > a technical code discussion for a non-technical or subjective issue.
> >
>
> First, it's important to recall that whether under CTR or RTC,
> there is always Review. If people, after something has
> been committed under CTR has issues with it, then
> that is Reviewing it after all. We already discussed
> technical voting, but what about "direction" or "vision"
> review. Or, as you said in a previous Email:
>
> > ... a polite way of  saying:
> >
> > "Hey, nothing wrong with the code itself, but I don't think there
> > is enough
> > support from
> > the community for the direction you're going - could you confirm
> > that a
> > majority and
> > at least 3 people think it fits our goals ?"
>
>
>
> That's still part of the review process... Vetoes are
> there to prevent code from being committed, but not
> all reviews are for the functional aspects of the
> actual code but rather to determine how much support
> there is for an implementation or feature... So I would
> say that this is still a valid and expected part
> of the R in *both* CTR and RTC.
>
> The thing is, of course, one cannot veto code based
> on non-technical reasons, but one can certainly review
> it based on such reasons and ask for some guidance that
> it makes sense. IMO, most of those types of cases
> should fall into the following types:
>
>1. People who agree and will help support it,
>   implement it, etc... (+1)
>2. People who don't care one way or another. (+0)
>3. People who don't like it, but hey, if it helps
>   you out and there are other people behind it,
>   I won't stand in your way. (-0.9)
>4. I don't like it and this is why. It would be
>   a mistake. (-1)



+1

If possible, add 5 and 6:

5. I may like it, but as a module that is not enabled by default.

6. I may like it, but as a standalone module, easy to download and install,
but not bundled
in the base distro.

Both 5 and 6 should be counted as -0.9 on the change itself, but as +0.9 if
the
concern is addressed.

Yes, if everyone understand this - and we stop using early commit/lazy
consensus
 and veto to get around R by a larger set of people - big +1.

I  like CTR and having an official trunk where active development happens -
but I don't like the endless discussion about veto validity and some big
changes
made without consensus or consultation - that was the main reason I support
a partial RTC until people get used to the idea of getting a +3 for
important changes.

Costin

Re: Review model take 2

[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 the majority and 3+1 process - and
we're
done.

As you know - some people are complaining that veto is abused ( and
that's
right ),
many Rs turn into flame wars and get personal - so the issue is how
to avoid

a technical code discussion for a non-technical or subjective issue.



First, it's important to recall that whether under CTR or RTC,
there is always Review. If people, after something has
been committed under CTR has issues with it, then
that is Reviewing it after all. We already discussed
technical voting, but what about "direction" or "vision"
review. Or, as you said in a previous Email:


... a polite way of  saying:

"Hey, nothing wrong with the code itself, but I don't think there
is enough
support from
the community for the direction you're going - could you confirm
that a
majority and
at least 3 people think it fits our goals ?"




That's still part of the review process... Vetoes are
there to prevent code from being committed, but not
all reviews are for the functional aspects of the
actual code but rather to determine how much support
there is for an implementation or feature... So I would
say that this is still a valid and expected part
of the R in *both* CTR and RTC.

The thing is, of course, one cannot veto code based
on non-technical reasons, but one can certainly review
it based on such reasons and ask for some guidance that
it makes sense. IMO, most of those types of cases
should fall into the following types:

   1. People who agree and will help support it,
  implement it, etc... (+1)
   2. People who don't care one way or another. (+0)
   3. People who don't like it, but hey, if it helps
  you out and there are other people behind it,
  I won't stand in your way. (-0.9)
   4. I don't like it and this is why. It would be
  a mistake. (-1)




+1

If possible, add 5 and 6:

5. I may like it, but as a module that is not enabled by default.

6. I may like it, but as a standalone module, easy to download and  
install,

but not bundled
in the base distro.



Assuming some sort of module impl exists, yes, of course.

Both 5 and 6 should be counted as -0.9 on the change itself, but as  
+0.9 if

the
concern is addressed.

Yes, if everyone understand this - and we stop using early commit/lazy
consensus
 and veto to get around R by a larger set of people - big +1.

I  like CTR and having an official trunk where active development  
happens -
but I don't like the endless discussion about veto validity and  
some big

changes
made without consensus or consultation - that was the main reason I  
support

a partial RTC until people get used to the idea of getting a +3 for
important changes.

Costin



I think all this handles the obvious and some of the non-obvious
holes that had been in place...

Should we call a vote?? Or just assume lazy consensus?
*duck*

PS: That was *a joke* ! :)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Test - please ignore

[Mark Thomas]

Wiki config test.

Mark

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Tomcat Wiki] Update of "JakartaTomcat" by markt

[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.

--
  
  Tomcat was one of the Jakarta subprojects, is now a top-level project and and 
has its home page at http://tomcat.apache.org/.
  
- TomcatProjectPages is a good starting point for reading more information 
about Tomcat, and is ''highly'' recommended.
+ FrontPage is a good starting point for reading more information about Tomcat, 
and is ''highly'' recommended.
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Wiki diffs

[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 have just fixed this so, my
suggestion is to use the wiki for this.

Once we have the agreed guidelines, we can add them to the Tomcat web
pages, probably linked from get involved.

Mark

PS I would volunteer to write the first draft but I am meant to be on
holiday and if I spend any more time on my laptop tonight, I am going to
be in trouble ;)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]