> 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?
