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: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Date Sat, 22 Sep 2007 22:01:00 GMT
this email is so unclean, I'm a bit confused on the exact bullets, mind 
posting a new thread?

Filip

Jim Jagielski wrote:
>
> On Sep 21, 2007, at 4:36 PM, Jim Jagielski wrote:
>
>>
>> On Sep 21, 2007, at 4:27 PM, Costin Manolache wrote:
>>
>>> On 9/21/07, Jim Jagielski <jim@jagunet.com> 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...
>>
>
> I'd like to call a vote on acceptance of the above methodology,
> as crafted and fine-tuned by Costin and myself. It is worthwhile
> to note that, really, these are the typical ASF methods, but
> with some "grainy" aspects better defined. In essence, some
> typical "niceties" are now mandated (changes, even in CTR, which
> affect the API, must be brought up first to gauge community
> approval).
>
>    [ ] +1. Yes, the above works and addresses my concerns
>            as well as the problems which started this whole
>            thing.
>    [ ]  0. Whatever.
>    [ ] -1. The above does not work for the following reasons:
>
> The vote will run for 96 hours instead of the normal 72 because of
> the weekend. Only binding votes will be counted, but non-binding
> votes will be used to address wider concern/acceptance of
> the proposal.
>
>
> ---------------------------------------------------------------------
> 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