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

Reply via email to