[OE-core] Patch merge process

[Otavio Salvador]

On Thu, Sep 10, 2015 at 12:39 PM, Martin Jansa <martin.jansa at gmail.com> wrote:
> On Thu, Sep 10, 2015 at 06:23:07PM +0300, Alexander Kanevskiy wrote:
...
>> might be. I haven't checked latest versions 2.10+, but versions below were
>> not up to the shape compared to e.g. pull-request workflow in GitHub.
>
> GitHub's pull-request workflow model is even worse than e-mail reviews
> on ML.
>
> It doesn't even support doing inline comments, because as soon as the
> "source" branch is rebased or just amended to address the review
> comments from v1, it will loose reference to all these comments, because
> the commits will look "new" (different git SHA).
>
> That's completely useless for good review, I want to compare different
> revisions of the same patch, to see what comments I had before and how
> they were addressed in new version. Github doesn't support anything like
> that, people are using different work-arounds like opening new
> pull-request for each revision (which means you need to always push to
> new branch) or listing the commit SHAs inside the global "comments"
> section, so that very patient reviewer can open the older revisions and
> do manual diff (by switching between 2 browser tabs back and forth
> trying to spot the differences or whatever).
>
> Atlassian Stash has exactly the same problem, ReviewBoard the same, they
> all think that to address review comments you just add another commit on
> top of your branch to fix the issues you introduced in submitted commits
> - but that's useless for code quality, bisect-ability etc. We don't want
> 10 garbage changes with incorrect commit messages and 11th change on top
> which fixes the issues, we're doing review so that each change is
> meaningful, build-able, test-able and properly documented in commit
> message - that's all I want to ensure by using code review tool and only
> Gerrit allows to do it efficiently.
>
> Gerrit shows all revisions of the same patch (as long as Change-Id is
> the same) in the same UI, allows you to see diff between any 2
> revisions including comments on them etc).
>
> Only people who never got used to do detailed reviews in Gerrit can say
> that Github's pull-request are "review-tool".
>
> You can see similar discussion e.g. lately in systemd ML after they
> moved to github "for better reviews".

I fully support Gerrit for it. It does has improved how our team work
internally and we don't regret of moving to it.

I like GitHub but for serious review it does a bad job; as community it is nice.

>> GitHub's model is to fork repository, do any amount of modification in your
>> own copy and then open "pull-request" for review where you just specify
>> source/destination repositories and branches with set of changes.
>>
>> Gitlab comment was practically to have similar to GitHub workflow, but
>> instead of public's GitHub service to have instance on openembedded.org
>> infrastructure, and thus requiring users to register accounts there.
>
> But we want to depend on well-maintained external service like we depend
> on github.com to mirror our repositories and we ask our users to use
> github mirrors instead of git.openembedded.org.
>
> Similarly we can depend on http://gerrithub.io/ to host our gerrit
> instance to save some maintenance for people with access to
> openembedded.org infrastructure.

If desired we can host it in one of our machine and provide an
exclusive VM for OpenEmbedded to use.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750