hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Nauroth <cnaur...@hortonworks.com>
Subject Re: Branch policy question
Date Wed, 23 Mar 2016 21:20:09 GMT
It's interesting to go back to the change in bylaws in 2011 that
introduced the requirement for 3 binding +1s on a branch merge [1].  The
text of that resolution suggests that it's supportive of
commit-then-review if that's what the developers on the branch want to do.

"Branches' commit requirements are determined by the branch maintainer and
in this situation are often set up as commit-then-review."

It would also be very much against the spirit of that resolution to
combine it all down into a single patch file and get a single +1.

"As such, there is no way to guarantee that the entire change set offered
for trunk merge has had a second pair of eyes on it.  Therefore, it is
prudent to give that final merge heightened scrutiny, particularly since
these branches often extensively affect critical parts of the system.
Requiring three binding +1s does not slow down the branch development
process, but does provide a better chance of catching bugs before they
make their way to trunk."

--Chris Nauroth

[1] https://s.apache.org/iW1F



On 3/23/16, 2:11 PM, "Steve Loughran" <stevel@hortonworks.com> wrote:

>
>> On 22 Mar 2016, at 18:23, Andrew Wang <andrew.wang@cloudera.com> wrote:
>> 
>> A branch sounds fine, but how are we going to get 3 +1's to merge it? If
>> it's hard to find one reviewer, seems even harder to find two.
>
>Given that only one +1 is needed to merge a non-branch patch, he could in
>theory convert the entire branch into a single .patch for review. Not
>that I'd encourage that, just observing that its possible
>
>
>> 
>> On Tue, Mar 22, 2016 at 10:56 AM, Allen Wittenauer <
>> allenwittenauer@yahoo.com.invalid> wrote:
>> 
>>> 
>>>> On Mar 22, 2016, at 10:49 AM, larry mccay <larry.mccay@gmail.com>
>>>>wrote:
>>>> 
>>>> That sounds like a reasonable approach and valid use of branches to
>>>>me.
>>>> 
>>>> Perhaps a set of functional tests could be provided/identified that
>>>>would
>>>> help the review process by showing backward compatibility along with
>>>>new
>>>> extensions for things like dynamic commands?
>>>> 
>>> 
>>>        This is going into trunk, so no need for backward compatibility.
>>> 
>
>


Mime
View raw message