hadoop-mapreduce-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin P. McCabe" <cmcc...@apache.org>
Subject Re: DISCUSSION: Patch commit criteria.
Date Mon, 02 Mar 2015 18:32:47 GMT
I agree with Andrew and Konst here.  I don't think the language is
unclear in the rule, either... "consensus with a minimum of one +1"
clearly indicates that _other people_ are involved, not just one

I would also mention that we created the "branch committer" role
specifically to make it easier to do rapid development on a new
feature.  Branch committers can commit patches to a branch without any
full committers involved at all.  When the branch is ready to merge,
the community can review it and give feedback.


On Fri, Feb 27, 2015 at 2:27 PM, Andrew Wang <andrew.wang@cloudera.com> wrote:
> I have the same interpretation as Konst on this. +1 from at least one
> committer other than the author, no -1s.
> I don't think there should be an exclusion for trivial patches, since the
> definition of "trivial" is subjective. The exception here is CHANGES.txt,
> which is something we really should get rid of.
> Non-committers are still strongly encouraged to review patches even if
> their +1 is not binding. Additional reviews improve code quality. Also,
> when it comes to choosing new committers, one of the primary things I look
> for is a history of quality code reviews.
> Best,
> Andrew
> On Fri, Feb 27, 2015 at 1:04 PM, Konstantin Shvachko <shv.hadoop@gmail.com>
> wrote:
>> There were discussions on several jiras and threads recently about how RTC
>> actually works in Hadoop.
>> My opinion has always been that for a patch to be committed it needs an
>> approval  (+1) of at least one committer other than the author and no -1s.
>> The Bylaws seem to be stating just that:
>> "Consensus approval of active committers, but with a minimum of one +1."
>> See the full version under Actions / Code Change
>> <http://hadoop.apache.org/bylaws.html#Decision+Making>
>> Turned out people have different readings of that part of Bylaws, and
>> different opinions on how RTC should work in different cases. Some of the
>> questions that were raised include:
>>  - Should we clarify the Code Change decision making clause in Bylaws?
>>  - Should there be a relaxed criteria for "trivial" changes?
>>  - Can a patch be committed if approved only by a non committer?
>>  - Can a patch be committed based on self-review by a committer?
>>  - What is the point for a non-committer to review the patch?
>> Creating this thread to discuss these (and other that I sure missed) issues
>> and to combine multiple discussions into one.
>> My personal opinion we should just stick to the tradition. Good or bad, it
>> worked for this community so far.
>> I think most of the discrepancies arise from the fact that reviewers are
>> hard to find. May be this should be the focus of improvements rather than
>> the RTC rules.
>> Thanks,
>> --Konst

View raw message