Re: Review model take 2

[Remy Maucherat]

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
programmatically

yes, makes sense

- 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

-1. There is a huge risk for "I simply don't like it, revert it".
Anything that is to be rolled back, should be backed up by a technical
reason. So in this case, how do you define "it hinders concurrent work".
Either we do RTC or we don't, but having a vague definition in between,
doesn't make sense.


That is not: "I simply don't like it, revert it" that is "I think it
needs review, revert it and let's discuss it".
I would proposed that the one that does the -1 should come with another
fix in few days for a fix for a PR, another proposal for API/conf
changes and participate to the discussion on the -1 otherwise the -1
would become is invalid.


The patch does not need to be reverted when under review, except if 
there's a need to tag a release or something similar. In that case, 
including such a patch would not be acceptable. The other case is if it 
causes development issues, but it should be extremely rare (as API 
changing patches would get reviewed before being committed).


I also don't think any reason needs to be given for voting against a 
particular patch under review. If only one committer votes "no", then 
you need one additional "yes" (4 total), which sounds achievable. If two 
committers vote "no" (most likely you would be in a veto situation at 
the moment) then it's still doable if everybody else wants it. With 3 
against, the community is basically split, and it seems impossible to 
follow through without changes to convince the other camp.


The general idea is to be able to disagree with something without using 
something absolute like the veto mechanism, since the only thing that is 
going to be examined (at least at the moment) seems to be its validity. 
Also, if a vote is tied to a justification, then any discussions will 
immediately switch over from technical to "let's show the justification 
is not valid, so that we can ignore it" mode.


If it turns this new mechanism does not work, then I think new proposals 
can be made to change it quite easily.


Rémy


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

Re: Review model take 2

[Bill Barker]

+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 ):
> - adding new hooks to allow such features to be developed and plugged in 
> as
> separate modules
>
> For any new feature or bigger change to a component that already has a
> plugin mechanism ( connector, etc ) -
> it would be better to have it developed as an optional module ( i.e. not
> included in the default build, but
> as a separate jar that can be easily installed in lib/ ), and after it 
> gets
> released, tested, etc - it could
> be moved to the official distro based on a similar vote.
>
> That would mean that any 'itch scratching', new feature or major change 
> can
> still be done in CTR mode,
> in the main branch (instead of sandbox), and be usable.
>
> Costin
>
> On 9/18/07, Remy Maucherat <[EMAIL PROTECTED]> 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]

Re: Review model take 2

[jean-frederic clere]

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 either from confirguration or
 programmatically
>>> yes, makes sense
 - 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
>>> -1. There is a huge risk for "I simply don't like it, revert it".
>>> Anything that is to be rolled back, should be backed up by a technical
>>> reason. So in this case, how do you define "it hinders concurrent work".
>>> Either we do RTC or we don't, but having a vague definition in between,
>>> doesn't make sense.
>>
>> That is not: "I simply don't like it, revert it" that is "I think it
>> needs review, revert it and let's discuss it".
>> I would proposed that the one that does the -1 should come with another
>> fix in few days for a fix for a PR, another proposal for API/conf
>> changes and participate to the discussion on the -1 otherwise the -1
>> would become is invalid.
> 
> The patch does not need to be reverted when under review, except if
> there's a need to tag a release or something similar.

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.

Cheers

Jean-Frederic

> In that case,
> including such a patch would not be acceptable. The other case is if it
> causes development issues, but it should be extremely rare (as API
> changing patches would get reviewed before being committed).
> 
> I also don't think any reason needs to be given for voting against a
> particular patch under review. If only one committer votes "no", then
> you need one additional "yes" (4 total), which sounds achievable. If two
> committers vote "no" (most likely you would be in a veto situation at
> the moment) then it's still doable if everybody else wants it. With 3
> against, the community is basically split, and it seems impossible to
> follow through without changes to convince the other camp.
> 
> The general idea is to be able to disagree with something without using
> something absolute like the veto mechanism, since the only thing that is
> going to be examined (at least at the moment) seems to be its validity.
> Also, if a vote is tied to a justification, then any discussions will
> immediately switch over from technical to "let's show the justification
> is not valid, so that we can ignore it" mode.
> 
> If it turns this new mechanism does not work, then I think new proposals
> can be made to change it quite easily.
> 
> 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]

Re: Review model take 2

[Mladen Turk]

+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 draft as header.
I can also create a xml that can be added to the t.a.org
(updating http://tomcat.apache.org/getinvolved.html perhaps?)


Regards,
Mladen


Remy Maucherat wrote:

Hi,

Another more precise draft.



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

Re: Review model take 2

[Filip Hanik - Dev Lists]

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) on
APIs which are accessible to the user either from confirguration or
programmatically
  

yes, makes sense


- 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
  

-1. There is a huge risk for "I simply don't like it, revert it".
Anything that is to be rolled back, should be backed up by a technical
reason. So in this case, how do you define "it hinders concurrent work".
Either we do RTC or we don't, but having a vague definition in between,
doesn't make sense.


That is not: "I simply don't like it, revert it" that is "I think it
needs review, revert it and let's discuss it".
I would proposed that the one that does the -1 should come with another
fix in few days for a fix for a PR, another proposal for API/conf
changes and participate to the discussion on the -1 otherwise the -1
would become is invalid.
  

The patch does not need to be reverted when under review, except if
there's a need to tag a release or something similar.



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.
  


so to me this is spanking clear, that the process is vague, and before 
anything like this is implemented, it should be as black and white as 
RTC and CTR if it's gonna work
at this point, the vote doesn't make sense, as it is obvious folks 
aren't clear on the process being voted on.


Filip

Cheers

Jean-Frederic

  

In that case,
including such a patch would not be acceptable. The other case is if it
causes development issues, but it should be extremely rare (as API
changing patches would get reviewed before being committed).

I also don't think any reason needs to be given for voting against a
particular patch under review. If only one committer votes "no", then
you need one additional "yes" (4 total), which sounds achievable. If two
committers vote "no" (most likely you would be in a veto situation at
the moment) then it's still doable if everybody else wants it. With 3
against, the community is basically split, and it seems impossible to
follow through without changes to convince the other camp.

The general idea is to be able to disagree with something without using
something absolute like the veto mechanism, since the only thing that is
going to be examined (at least at the moment) seems to be its validity.
Also, if a vote is tied to a justification, then any discussions will
immediately switch over from technical to "let's show the justification
is not valid, so that we can ignore it" mode.

If it turns this new mechanism does not work, then I think new proposals
can be made to change it quite easily.

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

[Remy Maucherat]

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 avoid reverting a patch until the 
review is concluded (or there is passing review on a patch which 
supersedes it), as it wastes time and is annoying to do. The main other 
issues are to determine:

- how long a review should last (most likely, the usual one week would do)
- the passing margin (+3 could be +2, for example)

Rémy


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

Re: Review model take 2

[jean-frederic clere]

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 possible, I would like to avoid reverting a patch until the
> review is concluded (or there is passing review on a patch which
> supersedes it), as it wastes time and is annoying to do.

Ok. Reverting it doesn't force the ones that disagree to react quicky
once reverted.

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 passing margin
of +3.

Cheers

Jean-Frederic

> The main other
> issues are to determine:
> - how long a review should last (most likely, the usual one week would do)
> - the passing margin (+3 could be +2, for example)
> 
> 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]

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

[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=43423





--- Additional Comments From [EMAIL PROTECTED]  2007-09-19 10:15 ---
Isn't the point of -force to stop the jvm with wild abandon?

1) I think the existing behavior here is pretty appropriate
2) -force really shouldn't be depended upon to leave the environment in a sane
state, but I would expect it to return quickly (possibly leaving a trail of
bloodied jvms in its wake)

-- 
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 43423] - catalina.sh -force too fast

[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=43423





--- Additional Comments From [EMAIL PROTECTED]  2007-09-19 10:32 ---
Actually - I'd prefer look for an env variable called CATALINA_WAIT and if it 
exists - optionally sleep for that amount of time

-- 
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 43423] - catalina.sh -force too fast

[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=43423





--- Additional Comments From [EMAIL PROTECTED]  2007-09-19 10:53 ---
Good idea. At least the default behavior doesn't change.

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

[William A. Rowe, Jr.]

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 passing margin
> of +3.

A higher bar to add a feature than to release the software?  Plainly absurd.

Majority is more than sufficient for almost any decision (more + than -)
so long as you have at least three affirmative votes.  The only exception
would be to undoing the decision of the PMC, such as booting a person from
the project or 'unreleasing' a release (not that this would make any sense).
Those sorts of decisions *need* a supermajority (60 - 75% or even unanimous
decision, depending on what rules the committee follows) to undo what the
majority had settled on before.

That is unless you plan to shutter the project, which is what much of this
discussion seems to be about.  Set up as many obstacles to changing Tomcat,
until Tomcat stagnates entirely, and surrenders to that Glassfish thing?

If the project wants to remain relevant, it needs a healthy community,
which means attracting instead of repulsing people, and it needs.   And
it needs to provide an opportunity for people to innovate, not many of
the folks here suck on the corporate tit for their camping at Tomcat, and
are "happy" to do allot of nothing.  Creativity is the energy behind the
success of ASF projects.  Deny your contributors the opportunity to solve
problems creatively, and you might as well hang out the "Closed" sign out
on the http://tomcat.apache.org/ page already.

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.

But without reestablishing a method for the committers to innovate, or
with continued/renewed territorial behaviors, this issue will likely
be noticed again by the board a few months from now as an issue in need
of a solution.

Bill

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

Re: Review model take 2

[Costin Manolache]

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/improving any
component in tomcat
should stay CTR and should be encouraged and supported. Anyone can create
Valves, Connectors,
Jndi implementations, class loaders or almost anything else that can be
plugged into tomcat
via config file - and a change to add more hook points shouldn't be hard to
get in.

However - for new features that want to be bundled with tomcat, or for
important or
controversial changes ( defined as 'no consensus' - and one person in
disagreement means
no consensus ) - a majority vote should resolve the question and avoid any
personal or one-on-one
fights.

Consensus is simple to determine - and so is lack of consensus for any
feature. If Remy and Filip
( and all other committers who care about something ) are in consensus -
done. If there is
doubt - involving and asking more people seems the right solution.

I think it is a big mistake to use the sandbox as a way to avoid
confrontation -  or to waste time
debating subjective things like what is better among 2 not-so-obviously bad
solutions ( which is
what causes most hurt feelings ). Implement any feature  you want in a
module, pack it as a jar
 with instructions on how to use it, get 3 +1s to release it - and after it
gets some testing and
traction - request it to be part of standard distro or the default
JNDI/Connector/ClassLoader/etc.
 Easy, no conflicts needed, good for both tomcat and the feature itself. If
someone else can
implement it in a better way - new vote will get the other one.


Costin

On 9/19/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> 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 solution is found. I would keep a passing margin
> > of +3.
>
> A higher bar to add a feature than to release the software?  Plainly
> absurd.
>
> Majority is more than sufficient for almost any decision (more + than -)
> so long as you have at least three affirmative votes.  The only exception
> would be to undoing the decision of the PMC, such as booting a person from
> the project or 'unreleasing' a release (not that this would make any
> sense).
> Those sorts of decisions *need* a supermajority (60 - 75% or even
> unanimous
> decision, depending on what rules the committee follows) to undo what the
> majority had settled on before.
>
> That is unless you plan to shutter the project, which is what much of this
> discussion seems to be about.  Set up as many obstacles to changing
> Tomcat,
> until Tomcat stagnates entirely, and surrenders to that Glassfish thing?
>
> If the project wants to remain relevant, it needs a healthy community,
> which means attracting instead of repulsing people, and it needs.   And
> it needs to provide an opportunity for people to innovate, not many of
> the folks here suck on the corporate tit for their camping at Tomcat, and
> are "happy" to do allot of nothing.  Creativity is the energy behind the
> success of ASF projects.  Deny your contributors the opportunity to solve
> problems creatively, and you might as well hang out the "Closed" sign out
> on the http://tomcat.apache.org/ page already.
>
> 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.
>
> But without reestablishing a method for the committers to innovate, or
> with continued/renewed territorial behaviors, this issue will likely
> be noticed again by the board a few months from now as an issue in need
> of a solution.
>
> Bill
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Review model take 2

[Bill Barker]

"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 be:
>> - API changing patches (any protected or above signature change) on
>> APIs which are accessible to the user either from confirguration or
>> programmatically
>>
> yes, makes sense
>
>> - 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
>>
> -1. There is a huge risk for "I simply don't like it, revert it".
> Anything that is to be rolled back, should be backed up by a technical
> reason. So in this case, how do you define "it hinders concurrent 
> work".
> Either we do RTC or we don't, but having a vague definition in 
> between,
> doesn't make sense.
>
 That is not: "I simply don't like it, revert it" that is "I think it
 needs review, revert it and let's discuss it".
 I would proposed that the one that does the -1 should come with another
 fix in few days for a fix for a PR, another proposal for API/conf
 changes and participate to the discussion on the -1 otherwise the -1
 would become is invalid.

>>> The patch does not need to be reverted when under review, except if
>>> there's a need to tag a release or something similar.
>>>
>>
>> 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.
>>
>
> so to me this is spanking clear, that the process is vague, and before 
> anything like this is implemented, it should be as black and white as RTC 
> and CTR if it's gonna work
> at this point, the vote doesn't make sense, as it is obvious folks aren't 
> clear on the process being voted on.
>

And, yet again, Filip chooses to question the validity of the vote, instead 
of discussing ideas :(.  Now I feel insulted as well, since I'm fully aware 
on the process being voted on.  But if I lived with Jon in the same 
community, I can live with Filip ;-).

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 discussion took place on the list). 
However, I'll go with whatever the community consensus is on this point.

> Filip
>> Cheers
>>
>> Jean-Frederic
>>
>>
>>> In that case,
>>> including such a patch would not be acceptable. The other case is if it
>>> causes development issues, but it should be extremely rare (as API
>>> changing patches would get reviewed before being committed).
>>>
>>> I also don't think any reason needs to be given for voting against a
>>> particular patch under review. If only one committer votes "no", then
>>> you need one additional "yes" (4 total), which sounds achievable. If two
>>> committers vote "no" (most likely you would be in a veto situation at
>>> the moment) then it's still doable if everybody else wants it. With 3
>>> against, the community is basically split, and it seems impossible to
>>> follow through without changes to convince the other camp.
>>>
>>> The general idea is to be able to disagree with something without using
>>> something absolute like the veto mechanism, since the only thing that is
>>> going to be examined (at least at the moment) seems to be its validity.
>>> Also, if a vote is tied to a justification, then any discussions will
>>> immediately switch over from technical to "let's show the justification
>>> is not valid, so that we can ignore it" mode.
>>>
>>> If it turns this new mechanism does not work, then I think new proposals
>>> can be made to change it quite easily.
>>>
>>> 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

[William A. Rowe, Jr.]

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
> Valves, Connectors,
> Jndi implementations, class loaders or almost anything else that can be
> plugged into tomcat
> via config file - and a change to add more hook points shouldn't be hard to
> get in.
> 
> However - for new features that want to be bundled with tomcat, or for
> important or
> controversial changes ( defined as 'no consensus' - and one person in
> disagreement means
> no consensus ) - a majority vote should resolve the question and avoid any
> personal or one-on-one fights.
> 
> Consensus is simple to determine - and so is lack of consensus for any
> feature. If Remy and Filip
> ( and all other committers who care about something ) are in consensus -
> done. If there is
> doubt - involving and asking more people seems the right solution.

++1

> I think it is a big mistake to use the sandbox as a way to avoid
> confrontation -  or to waste time
> debating subjective things like what is better among 2 not-so-obviously bad
> solutions ( which is
> what causes most hurt feelings ). Implement any feature  you want in a
> module, pack it as a jar
>  with instructions on how to use it, get 3 +1s to release it - and after it
> gets some testing and
> traction - request it to be part of standard distro or the default
> JNDI/Connector/ClassLoader/etc.
>  Easy, no conflicts needed, good for both tomcat and the feature itself. If
> someone else can
> implement it in a better way - new vote will get the other one.

Well said, all the way around.

Thanks,

Bill

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

Re: Review model take 2

[William A. Rowe, Jr.]

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 discussion took place on the list). 
> However, I'll go with whatever the community consensus is on this point.

But isn't that statement too broad (to apply to trunk, I agree that in a
ready-to-release anytime sort of branch, disputed things should disappear
for a while)...

It's in the context.  If Joe suggests "hey, -1 to the way you presented
that, if you fix X you have my support" then it should stick a round a
while and let them sort it out.

If Joe says "this feature isn't going to be acceptable because Y", well
then there isn't much to discuss at that point, and it probably should be
backed out right away while the basic idea is debated.

Clear A/B options sometimes aren't that effective.

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

Re: Review model take 2

[Bill Barker]

"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 discussions should stay
>> in the "STATUS" until a solution is found. I would keep a passing margin
>> of +3.
>
> A higher bar to add a feature than to release the software?  Plainly 
> absurd.
>
> Majority is more than sufficient for almost any decision (more + than -)
> so long as you have at least three affirmative votes.  The only exception
> would be to undoing the decision of the PMC, such as booting a person from
> the project or 'unreleasing' a release (not that this would make any 
> sense).
> Those sorts of decisions *need* a supermajority (60 - 75% or even 
> unanimous
> decision, depending on what rules the committee follows) to undo what the
> majority had settled on before.
>
> That is unless you plan to shutter the project, which is what much of this
> discussion seems to be about.  Set up as many obstacles to changing 
> Tomcat,
> until Tomcat stagnates entirely, and surrenders to that Glassfish thing?
>
> If the project wants to remain relevant, it needs a healthy community,
> which means attracting instead of repulsing people, and it needs.   And
> it needs to provide an opportunity for people to innovate, not many of
> the folks here suck on the corporate tit for their camping at Tomcat, and
> are "happy" to do allot of nothing.  Creativity is the energy behind the
> success of ASF projects.  Deny your contributors the opportunity to solve
> problems creatively, and you might as well hang out the "Closed" sign out
> on the http://tomcat.apache.org/ page already.
>
> 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.

> But without reestablishing a method for the committers to innovate, or
> with continued/renewed territorial behaviors, this issue will likely
> be noticed again by the board a few months from now as an issue in need
> of a solution.
>

I maintain that there is currently a very small barrier to "innovating" on 
Tomcat.  We had one innovation that was shown to have a big whopping 
security hole in it, so it was withdrawn until a better patch can be made 
(i.e. the system worked).  There were people (myself included) that would 
have preferred a modular patch (e.g. with httpd, I can configure it so that 
mod_alias isn't included with a few small edits, but the patch in question 
didn't allow for that, which was the complaints).



> Bill 




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

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

[markt]

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://svn.apache.org/viewvc/tomcat/site/trunk/docs/index.html?rev=577553&r1=577552&r2=577553&view=diff
==
--- tomcat/site/trunk/docs/index.html (original)
+++ tomcat/site/trunk/docs/index.html Wed Sep 19 22:06:56 2007
@@ -265,7 +265,7 @@
 2.4/2.0
 
   
-5.5.23
+5.5.25
 
 
 

Modified: tomcat/site/trunk/xdocs/index.xml
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/index.xml?rev=577553&r1=577552&r2=577553&view=diff
==
--- tomcat/site/trunk/xdocs/index.xml (original)
+++ tomcat/site/trunk/xdocs/index.xml Wed Sep 19 22:06:56 2007
@@ -51,7 +51,7 @@
 
 
   2.4/2.0
-  5.5.23
+  5.5.25
 
 
 



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

Re: Review model take 2

[Bill Barker]

"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 immediately (and have done so on several occations, even 
>> when
>> I got to re-apply it after enough discussion took place on the list).
>> However, I'll go with whatever the community consensus is on this point.
>
> But isn't that statement too broad (to apply to trunk, I agree that in a
> ready-to-release anytime sort of branch, disputed things should disappear
> for a while)...
>

There is no trunk in Tomcat :), and likely won't be until the sooner of a 
[PROPOSAL] or the Servlet 3.0 spec is published.

As I said, personally I revert patches on a veto, pending discussion.  But 
I'm going to back the majority on this point whichever way it goes.

> It's in the context.  If Joe suggests "hey, -1 to the way you presented
> that, if you fix X you have my support" then it should stick a round a
> while and let them sort it out.
>
> If Joe says "this feature isn't going to be acceptable because Y", well
> then there isn't much to discuss at that point, and it probably should be
> backed out right away while the basic idea is debated.
>
> Clear A/B options sometimes aren't that effective. 




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

Re: Review model take 2

[Remy Maucherat]

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 solution is found. I would keep a passing margin
of +3.


A higher bar to add a feature than to release the software?  Plainly absurd.


The patches which would be put under review are:
- API or configuration changing patches
- those which are found to be risky, or simply in need of significant 
improvements


Features additions are not mentioned in my proposal. We also use a +3 
vote for releases.


Rémy

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