tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
Subject Re: Review model take 2
Date Thu, 20 Sep 2007 14:16:23 GMT
Bill Barker wrote:
> "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 ;-).
>   
how can we vote, if the thread goes into discussion. The ASF clearly has 
to methods of developing, CTR or RTC,
So there are two questions here
1. Why do we need something in between
2. This is the third time around this topic has been discussed, and 
folks are still unclear on the process or the desire thereof, you might 
be clear, but me, and others based on the thread for sure aren't. The 
new model is not black and white, but it would have to be in order to work.

I'd say, stick to what we know, the ASF ways. And Bill, thanks for 
comparing me to Jon. If you ever show up at an ApacheCon, the first beer 
will be on me :)

> 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.
>   
Yes, and I too appreciate the effort, although, I do think it's better 
to stick with the ASF ways, so that there is no question on how things 
should be done.
If you want development in a non ASF way, there are plenty of other 
places to do development than the ASF

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


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


Mime
View raw message