tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: Review model take 2
Date Thu, 20 Sep 2007 02:28:10 GMT

"Filip Hanik - Dev Lists" <devlists@hanik.com> wrote in message 
news:46F12965.2080404@hanik.com...
> 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: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>>
>> 




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message