tomcat-dev mailing list archives

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

"Filip Hanik - Dev Lists" <> wrote in message
> 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)
>>>>>> APIs which are accessible to the user either from confirguration
>>>>>> 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:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message