[Gluster-devel] Pull Request review workflow

Amar Tumballi amar at kadalu.io
Thu Oct 15 11:01:03 UTC 2020

Thanks for taking time on this, and sending this note Xavi!

Some comments inline!

On Thu, Oct 15, 2020 at 4:03 PM Xavi Hernandez <xhernandez at redhat.com>

> Hi all,
> after the recent switch to GitHub, I've seen that reviews that require
> multiple iterations are hard to follow using the old workflow we were using
> in Gerrit.
> Till now we basically amended the commit and pushed it again. Gerrit had a
> feature to calculate diffs between versions of the patch, so it was
> relatively easy to follow the changes between iterations (unless there was
> a big change in the base branch and the patch was rebased).
> In GitHub we don't have this feature (at least I haven't seen it). So I'm
> proposing to change this workflow.
> The idea is to create a PR with the initial commit. When a modification
> needs to be done as a result of the review, instead of amending the
> existing commit, we should create a new commit. From the review tool in
> GitHub it's very easy to check individual commits.

> Once the review is finished, the patch will be merged with the "Squash and
> Merge" option, that will combine all the commits into a single one before
> merging, so the end result will be exactly the same we had with Gerrit.
Just a note to the maintainers who are merging PRs to have patience and
check the commit message when there are more than 1 commits in PR.

Another thing to consider is that rfc.sh script always does a rebase before
> pushing changes. This rewrites history and changes all commits of a PR. I
> think we shouldn't do a rebase in rfc.sh. Only if there are conflicts, I
> would do a manual rebase and push the changes.
With github workflow, we don't need './rfc.sh' in my personal opinion. I
ported it to new branch and github considering the number of developers who
are used to it.  If you do the changes as per github, then you would have a
separate branch per PR (ie, feature/bug), so you are at your own to decide
when to rebase.

What do you think ?
I agree, we can remove -f option of ./rfc.sh and also the rebase part in


> Regards,
> Xavi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20201015/f60acc21/attachment-0001.html>

More information about the Gluster-devel mailing list