Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <46F5909C.20606@hanik.com>
Date: Sat, 22 Sep 2007 16:01:00 -0600
From: Filip Hanik - Dev Lists <devlists@hanik.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
References: <46F010DB.6000704@apache.org>
 <C053416A-1973-426A-9B00-48FA39ED2FA0@jaguNET.com>
 <96e4b5230709210812n132adc38jdf502a59c600aa3e@mail.gmail.com>
 <1D800057-5E3B-4DA5-B211-469880147BC5@jaguNET.com>
 <96e4b5230709211023h1052225x125edaddb2625646@mail.gmail.com>
 <CE914525-DA9B-4067-A999-66B269E7890E@jaguNET.com>
 <96e4b5230709211210r2090e46dy46a0f7e095641a4f@mail.gmail.com>
 <A863F680-BE6F-46DB-9925-E475DE6C23C9@jaguNET.com>
 <96e4b5230709211249h246d6e7ckd6d9248bd864bf86@mail.gmail.com>
 <2BD120D1-A92D-48AC-85C5-F33E0CF301EA@jaguNET.com>
 <96e4b5230709211327n5b007184p803f832c83e19136@mail.gmail.com>
 <7B36C007-E9C2-4EFA-B32D-1E5FA1E14E71@jaguNET.com>
 <DE16A841-B7F3-4E03-BAE4-64A225358A62@jaguNET.com>
In-Reply-To: <DE16A841-B7F3-4E03-BAE4-64A225358A62@jaguNET.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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