[Sugar-devel] Github review workflow

Walter Bender walter.bender at gmail.com
Tue Apr 2 14:13:51 EDT 2013


On Tue, Apr 2, 2013 at 1:47 PM, Manuel Quiñones <manuq at laptop.org> wrote:
> 2013/4/2 Daniel Narvaez <dwnarvaez at gmail.com>:
>> On 2 April 2013 16:43, Manuel Quiñones <manuq at laptop.org> wrote:
>>>
>>> > 7 Push the changes to another remote branch
>>>
>>> Is there a need for a new branch for each pull request?  Pushing again
>>> to the topic1 will automatically update the pull request in github.
>>
>>
>> The problem is when rebasing (i.e. making changes to any of the already
>> reviewed commits), which is a very very frequent case... You either need to
>> use another branch or to git push -f, which I'm not too comfortable with,
>> I'm worried I would it use it accidentally somewhere else if I got used to
>> it...
>>
>> Do you know how people generally deals with that case?
>
> No, it's worth taking a look at other open projects.
>
>> The only other option I can think of is to fix the reviewer complaints in
>> another commit, which I don't like much because it makes a mess of the
>> history.
>
> Yes, you are right.  Fixing by adding more commits is a mess.  So
> taking into account that, branching and opening another pull requests
> as you originally proposed makes sense.

I was a bit skeptical at first, but it has not been too painful.

-walter
>
>>>
>>> I think we should have shortcuts too, to not block too much.  For a
>>> simple patch for example, the maintainer could be able to add minor
>>> tweaks to the pull request and do a manual merge, instead of asking
>>> another reviewing loop.
>>
>>
>> Yup.
>
>
>
> --
> .. manuq ..
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org


More information about the Sugar-devel mailing list