[Sugar-devel] Github review workflow

[Manuel Quiñones]

2013/3/28 Daniel Narvaez <dwnarvaez at gmail.com>:
> Hi,
>
> I started experimenting a bit with github code reviews, with Walter as
> ginuea pig :) We wasn't too sure about stuff like rebasing, using
> separate branches etc, so tonight I played a bit myself with creating
> pull requests.
>
> Something like the following might be a decent start for a workflow
>
> 1 Create one branch per topic
>
> git checkout -b topic1
>
> 2 Make one or more commits
> 3 Push the branch
>
> git push origin topic1

Yeah, and testing will be encouraged in this branch.

> 4 Submit a pull request for the branch (web UI)
>
> 5a The reviewer merges the patch.
> 5b The reviewer rejects the patch (and closes the request).
> 5c The reviewer requires changes (and closes the request).
>
> If 5c:
>
> 6 Make changes using interactive rebase
> (http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages)
>
> git rebase -i master
>
> 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.

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.

> git push origin topic1:topic1-try2
>
> 8 Submit the new pull request (web UI)
>
>
> If someone has experience with github suggestions would be welcome.
> Otherwise I hope Walter will keep being the ginuea pig in this
> experiment  :)

--
.. manuq ..