I extremely disagree with the idea of using "proprietary" and expensive to learn technologies as opposed to a de-facto standard is a good way to filter good vs bad developers. I also strongly disagree with the idea that people cannot make progress and that "bad" developers who don't want to learn boring workflows that provide no added value to them need to be pushed away early so they don't even try contributing. In the end, everyone starts as a bad developer and grows as a better one. And I think it has applied to all of us here.
I also disagree with the distinction between "serioux" fixes and other fixes. As a reminder, some trivial changes (colors, labels) are actually creating a lot of a added-value to users; aren't those serious? Should we keep restraining "bad" developers from submitting trivial changes that none of the "good" developers had addressed so far?
All that seems very elitist to me; and to me, elitism is a clear anti-pattern in a community.
I personally definitely will be less effective after moving my Eclipse platform work to github, and I do have github experience, so I know what I'm talking about.
Note that I do not challenge your opinion here; I partly agree with it.
But can you please clarify which specific workflows of Gerrit you'd find missing in GitHub? It would be worth capturing them in the doc so we can investigate whether they have solution, and maybe investigate whether we can influence GitHub in providing a solution (they've been pretty receptive to a few requests I've made).
2) Looking how many gerrit patch sets are needed in a typical *non-trivial* review, I fear a single github PR will spam the git history with ~20-50+ commits. That would be insane, but could be prevented if we would allow squashing before merge - this need to be considered during move.
The decision of "squash and merge" vs "rebase and merge" would still belong to the reviewer IMO. And reviewers can also ask the submitters for restructuring commits if this is desirable.
Keep in mind that GitHub doesn't mandate anything about how and who merges stuff and the various quality gates; those are still in the hand of the projects and their committers.
3) As usually, the most interesting question is open - who will do all the releng work needed: create new workflow processes, jobs, validation tasks, creating groups/projects, managing users, updating poms, build scripts, jenkins instances, wikis etc? We *hope* someone else will do that, or is this work planned by foundation? That's for sure more than one man-month full time. Do we have already concrete resources assigned to do that work? Should we ask IDE working group here?
Things are less complex than you imagine, and I think we have several people highly qualified and experienced to deal with such migration properly. FWIW, the migration proposal is backed by the people who usually care about releng and no strong rejection comes from the "operational" crew.
Some details:
Creating GitHub repos and groups/users is done by Foundation when moving.
Adapting CI for reviews is just a matter of adapting or creating a few jobs. This is something that I already did when starting to use Jenkinsfile and it's relatively fast. It can all be done in half a day for all repos; or -once we have 1 working/template job- 15 minutes per repo.
Adapting build scripts for review was partly anticipated when adopting Jenkinsfile and would be very easy. We're talking about many 1 full day of work.
Updating poms is a trivial search and replace, maybe a few hours.
We don't need extra Jenkins instances.
Production build scripts can mostly be implemented just by changing some repos URLs, it's more work and more error-prone, but nothing fundamentally complicated.
4) Should we have *first* a pilot project for some "trivial" repository with small patches trafic, to both github / gitlab, and see how it goes, and AFTER the evaluation decide on the concrete platform?
A candidate would be eclipse.platform.team for example.
I also support an iterative approach.
