Being a Gerrit maintainer I am, of course, biased but nevertheless I would like to
point to a few things which may be neglected.
Besides proactively checking, for every open change, if it is mergeable into its target branch
Gerrit also proactively checks if an open change conflicts with any other open change. This is
the "Conflicts With" tab in the Gerrit's change screen. This way one can see which open changes
are conflicting with each other without having to merge any of them.
Don't know if Github proactively checks for conflicts between pull requests?
Fix-up vs patch-set model:
Github's pull requests encourage the fix-up working style: if something needs to be fixed
it is usually done in a new commit on top of the existing commits in the pull request.
Once such a pull request is merged, all the broken states are exposed in the branch history.
This may be a problem when using "git bisect" and "git blame".
Gerrit's patch-set model actually replaces the last patch-set (technically a commit)
with a new patch-set. The new patch-set is not a successor but really a replacement.
Once a change is merged only the last patch set is merged into the target branch.
The branch history doesn't contain previous patch sets of that change.
On 03/29/2016 10:52 PM, Tyler Jewell wrote:
It is challenging to organize your issues, keep them tagged to the right milestone, and to clean them up. The searching, sorting, organization of bugzilla is stronger.
But... anyone with a GitHub ID can participate in the discussion. And ultimately it creates an environment where more people are willing to contribute / comment / discuss.
So we are willing to absorb any administrative challenges to get this aspect.
So maybe a mechanism to log into Eclipse.org using a GitHub account would be helpful then?