On Thu, Sep 10, 2015 at 12:39 PM, Martin Jansa <[email protected]> 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 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
