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" <ste...@hortonworks.com> wrote: > >> On 22 Mar 2016, at 18:23, Andrew Wang <andrew.w...@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 < >> allenwittena...@yahoo.com.invalid> wrote: >> >>> >>>> On Mar 22, 2016, at 10:49 AM, larry mccay <larry.mc...@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. >>> > >
