Just to clarify, we are talking about a feature branch in which Allen and others that are working on the branch could commit without requiring 3 +1’s. Then, at some point, we will need 3 +1’s to merge the branch to trunk. Correct?
I think that if we have a set of usecases that are being added and those that are being reworked with test coverage for them all - maybe including manual testing scenarios - that we could find folks that would be willing to work with Allen to get it reviewed. I am listed as a branch committer. If my vote would count then I would be more than willing to lend a hand where I can - especially if we have the tests/instructions for testing. I think that we need to strike a balance of not inhibiting progress and at the same time not getting a patch so large that it can’t be reviewed. Colin's point is valid and a design document that calls out the areas that will need testing and general approach would help review volunteers. There is always a risk with branches that the change gets to a level of complexity that it is too hard to reasonably review. I think that the community should allow folks to take that risk and try and provide enough guidance and transparency for review. Any non-trivial branch effort should have a merge strategy for getting it reviewed, tested and merged. On Tue, Mar 22, 2016 at 9:46 PM, Gangumalla, Uma <uma.ganguma...@intel.com> wrote: > > is it possible for me to setup a branch, self review+commit to that > >branch, then request a branch merge? > Basically this is something like Commit-Then-Review(here review later) > process right. I have not seen we followed this approach here( not sure if > I missed some branches followed that). Even though original author code > quality is good, there would always be chances for missing somethings. So, > peer review is important because the other eye can catch some issues which > original author might overlooked (general review advantage :-)). In this > case for branch merge we need three +1s. if we face difficult in getting > one +1, then I am afraid that we may face more difficult to get reviewers > a the time of merge, because code base much larger than normal patch. Some > times we suggest contributors to split patches into multiple JIRAs of > patch size is becoming larger. It is better to find some reviewers for the > branch and creating branch could turn into healthy merge later. > > Colin suggestion sounds good to me. How about providing more details and > find some reviewers (who is more familiar in that area etc)? > > If this is general question question for branch policy MY answer is ³no² > for "self review+commit to that branch, then request a branch merge². But > for this kind of special cases where we are sure that we may not have > enough reviewers for branch, having dev mailing discussion about that > JIRA/branch proposal and see how to go about that changes may be good idea > instead of going ahead finishing work and raising merge vote thread ? > (Something like this what you did now :-)) > > Just my thoughts on this discussion. > > Thanks & Regards, > Uma > > On 3/22/16, 9:14 AM, "Allen Wittenauer" <a...@apache.org> wrote: > > >Since it¹s nearly impossible for me to get timely reviews for some build > >and script changes, is it possible for me to setup a branch, self > >review+commit to that branch, then request a branch merge? > >
