I think some folks have rightly pointed out the reasons to not switch but I think those have to viewed in context to the future - how long can we keep using Gerrit with its annoyingly high learning curve is the primary question? Is the transitionary, painful period for present Gerrit developers worth the potential new contributors - I believe it has a nuanced answer, but I still think it's one that's positive. Some people like GitHub and some people like GitLab, but what we do know is that a lot of people definitely don't like Gerrit, and I think we are in a good place to start moving towards something better (atleast relatively).
Topic on Talk:GitLab consultation
As someone who has used gerrit for around 5 years, github for a bit longer & gitlab for a lot less I still find gerrit the hardest to work with by a strong margin - I suspect I still don't know how use it 'properly' but the number one thing I hate is the way discussions on commits don't really flow. Since I'm often involved in upstreaming I often link to upstream PRs, with screenshots & all the UI niceness around discussions on PRs (I prefer the github UI but will go with gitlab at a pinch), and try to redirect discussion there rather than try to parse it out of gerrit.
I do like the +1 & +2 system in gerrit & the download links
As a counterpoint, I also use Github and Gerrit regularly and find Gerrit much easier for actually managing my commits. It would be nice if the discussion system was better, but you can always use Phabricator.
I find working with Gerrit much easier than working with Github. If you forced me to start using Github tomorrow it would be an "annoyingly high learning curve".
Isn't that to some extent muscle memory? I'm asking because I still have to open Gerrit/Tutorial for all the commands to run, every time I plan to push something for review into Gerrit.
It is the same in GitLab for me, but the number of steps isn't very different: If I don't fork I'd end up in GitLab with git checkout -b mybranch origin/master, edit, git add, git commit, and git push origin mybranch, and then create a merge request in the web UI.
Personally, the annoyingly high learning curve of gitlab isn't just about muscle memory (but it is in part!). It is about a completely different workflow for patches beyond a certain level of complexity.
Gerrit concepts map to git concepts very well, so if you understand git, Gerrit is super intuitive to use (not the UI, of course, but the patch wrangling part). Gerrit is basically just a git repo with a fancy web interface; changesets are basically just reflogs etc. The same is true for Github as well, except the Gerrit workflow models git rebase, and the Github workflow models git merge, and rebase is the one you actually want for any large projects because otherwise history becomes a mess and your ability to understand the codebase suffers. So with Github, you end up using a merge-like workflow while making sure that internally it's actually not merge-based at all. That mismatch makes it unintuitive, IMO.
I don't really agree with what Tgr said. If you're familiar with Git, Gerrit goes and adds gitreview on top of that to make it all that more complicated. I personally don't think it's "too" complicated but the notion that Gerrit is somehow more in line with standard Git workflow is misplaced. (And I'm saying this as someone who became aware of both Gerrit/GitLab/GitHub in the last 5 years.) If anything, GitLab/GitHub makes simple commits or even multiple simple commits that much easier to handle. For more complicated scenarios, I believe the experience is pretty much on par but fixing even a few of the myriad issues with using Gerrit makes it that much easier for our new folks. Furthermore, I don't agree that GitHub has to be a merge-based workflow, it's just more common, it differs from maintainer to maintainer and some of the repos even have settings to disallow merges in protected branches, most OSS repos will require you to rebase your pull request commits before they are squashed/rebased in.
Evety git-review command (except for the one setting up the commit hook) is a convenience wrapper around a basic git command. git-review -x does a cherry-pick. git-review -d does a checkout. git-review without an option does a push. It's more things to memorize, sure (especially with the shortkeys not being particularly sensible), but conceptually it is still a simple git command. You don't have to juggle multiple repositories, either (although in the end repositories and remotes are also simple concepts if you properly understand git's graph model).
As for rebase workflows in Github, the UX didn't really support them the last time I checked (you can do it, but you won't have a sensible audit trail, old comments won't really be useful...). And GitLab Comunity Edition does not seem to support stacked merge requests, much less rebasing them, but that has already been discussed in plenty other threads.
You're definitely correct in saying so. But I believe the short-term cost of transitioning is much lower than the long-term churn rate of potential new contributors because of Gerrit.
I think the main difference is that we know Gerrit pretty well, so we are sort of able to estimate how big an investment it would need to fix certain issues (rather big). With GitLab we don't know yet how many issues and how much friction we'll encounter in the first few years after adopting it, so it's easy to underestimate the costs.
I find GitHub to have a much more pleasing, inviting interface & workflow compared to Gerrit. However, once things become a little more complex, I (currently - possibly biased because I still used it way more often) heavily favour Gerrit.
It's easy to advertise a GitHub (-like) interface & workflow as being more inclusive & newcomer-friendly. It obviously is, but that means nothing unless those contributions end up getting merged (if not, we're only creating more frustration.) Being more friendly to newcomers is not a selling point until we can be assured that the workflow has no negative implications for repo maintainers (or are outweighed by the positives.)
I.e. pushing commit after commit onto a feature branch sure does seem simpler than carefully having to carefully maintain, amend & rebase a few dependant patches, but it's simply moving the cost up to the repository maintainer: code review becomes harder (code spread all over the place), and history becomes broken (unless commits get squashed after all.)
Someone has to pay for complexity: if it's not newcomers, then it's the maintainers (and if they are not willing or able to do it, the extra patches still aren't going anywhere.) I'm not currently sure how much of this "newcomer cost" GitLab would actually remove, and how much it would simply move the burden...