Yes, we can. However: triggering CI builds will be different; and I fear
changes in the builds will be required to get them triggered properly.
Reporting build results may also work differently. In any case the
GerritTrigger won't work.
Indeed, projects would have to add some Jenkinsfile and recreate jobs in CI as "multi-branch pipeline". It's an effort, but if you ask me, the result is better, more "configuration-as-code" which makes maintenance easier and more easily distributed.
I'm not keen on having to donate more of my volunteer time to revamp CI
builds and their integration with a git server.
Yes, that's something I think our Committer Representative need to mention. The amount of effort it's asking the community to do seem significantly higher to the amount of effort leaving some Gerrit server alive.
One crucial shortcoming of the PR model of Gitlab/Github is that there
is no support for PRs depending on other PRs. On Gerrit, I very often
have whole sequences of changes that depend on each other. This, and the
ability to group changes by topic, are two crucial features of Gerrit.
Ack.
Apart from that, Gitlab has a "squash on merge" feature for merging PRs
(or merge requests, as they call it), which makes it easier to deal with
clean-up commits in a PR (no need for amending and force pushing).
GitHub too, has "Squash and Merge" and "Rebase and Merge" actions, and repo admin can set one of them as default.
Asking contributors to amend and force push means the main benefit of
using a PR model falls away, namely that contributors just know how to
contribute since "everybody" knows the PR model from Github.
That was my first fear when I started working on GitHub projects, but actually contributors we got on those projects are OK squashing or amending their contributions. It hasn't been a concrete problem so far. We just need to explain, just like we often need to explain to push to "refs/for/master", keep Change-Id and so on with Gerrit.
