Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [egit-dev] Webmaster wants to get rid of Gerrit

On Sat, Nov 13, 2021 at 12:49 PM Thomas Wolf <thomas.wolf@xxxxxxxxxx> wrote:
On 12.11.21 23:41 , Matthias Sohn wrote:
> Hi,
> webmaster opened the issue
> since they want to get rid of Gerrit in favor of gitlab or github.

I saw that, too. But it's more: they also want to get rid of MediaWiki:

The EGit (and JGit) built-in documentation in Eclipse is generated from
the MediaWiki pages. So that will cause a lot of work for us. Or we just
drop the built-in help.

We also do the New & Noteworthy pages for EGit and JGit there.

They're also considering shutting down Bugzilla:

None of this new; such statements were aired on the Eclipse mailing
lists by members of the EMF server or web admin team several times
before. Always without clear and low-effort migration paths.

It makes me angry.

> What's your opinion?

If they do any of these, it'll cause a huge amount of work for us.

I don't have any extra time I could spend on such topics
I'm sick of these repeated threats to shut down the build and tracking
infrastructure we're using and that they've been providing. Doesn't make
me feel welcome at EMF.

same here
Reviews on Gerrit are far better than on Github. But I can do either.
Gitlab is not really an option for me; had to use it in some projects,
but I find it even clunkier than Github.

As for workflows: the Gerrit learning curve isn't really any steeper
than on Github. It takes comparable effort to teach a newcomer on Github
how to produce a clean PR that doesn't contain umpteen little fix
commits that just fix bugs in previous commits in the same PR.

Anecdotal evidence: I'm also a committer at Apache MINA sshd. I find
myself more often cleaning up PRs into a shape such that they can be
committed and, if necessary, also easily be reverted, than with Gerrit
reviews. And whenever I do that, I can't just push the result into the
repo; it wouldn't close the PR; I first have to force-push onto the PR
branch in the fork, and then push into the repo. (I can't use the Github
web UI for merging; my Github account has a several e-mails associated,
and Github insists on using the wrong one as "committer" if I do that.)

At work, we use Gerrit. New employees typically only have seen Github,
but I usually only have to tell them a few things, and then they are
perfectly capable of using Gerrit.

At SAP we use both github and gerrit and the learning curve for new
employees doesn't seem to be very different on either of them.
Perhaps gerrithub might be an option?

GerritForge is the company behind GerritHub, this means their offer is
to host the Eclipse projects which want to continue using Gerrit on GerritHub. 

But the larger issue is that moving elsewhere probably also means moving
the CI build infrastructure elsewhere.

I wouldn't expect that. Can't Eclipse projects hosted on also
use the Eclipse CI infrastructure ?
Plus there would need to be some
mirroring mechanism to a repo hosted at EMF, unless the EMF is really
ready to not even keep the sources of their projects anymore and
depending fully on some external commercial entity for that. Which I'd
find dumb, one simply doesn't put one's core assets completely into the
hands of someone else. There have been several cases recently and not so
recently where formerly "free" (as in beer) services suddenly became

(For mirroring, the EMF should really talk to the Apache people. They
have that solved with their Gitbox. Don't know how it works, but it
seems to be a multi-master setup between Github mirrors and their own
hosted repos. I can push commits at either repo, and they show up
correctly at both.)

> Options if we want to continue using Gerrit and webmaster doesn't
> provide it anymore:
>   * Take over the Eclipse gerrit instance on a project managed vserver
>     at Eclipse and run it ourselves. That's how we started using Gerrit
>     at Eclipse before the webmaster took it over.
>   * Move our repositories to a public managed Gerrit site. GerritForge
>     signaled they would be willing to host a Gerrit instance for Eclipse.

Or gerrithub?

that's the option GerritForge offers to us
Running our own Gerrit instance might be doable. With only a handful of
projects on it and a fairly low commit volume, it shouldn't be too hard.
We do that at work, and except for upgrades it's very low maintenance.
But it would burden us with also doing occasional server maintenance. A
managed Gerrit would be better. Feels like the EMF doesn't know how to
provide that, or just doesn't want to.

AFAIR we ran Gerrit for JGit and EGit ourselves for 1 or 2 years and since then
EF runs Gerrit. I remember Denis mentioning repeatedly that he likes running
Gerrit since it's low maintenance.

I would also prefer a managed service since we already have enough work
with maintaining our projects.
But wherever we'd move to, we still need working CI builds.

Finally: EGit (and JGit) currently participate in SimRel. Would moving
our git hosting and probably CI build infrastructure elsewhere have an
impact on that?



P.S.: if we'd use Github, we probably can forget about insisting on
reasonable commit messages, and on "one commit = one logical unit". I
don't see any PR author going back through several commits on a PR,
amending the commit messages, splitting or combining commits, and then
force-pushing again. And squash-merge isn't the answer to that problem.

yep, I share this concern and don't want to compromise on these principles.
Also, AFAIK Github CI checks only the top commit of a PR. So not all
commits are checked, and we'll end up with commits in the repos that
leave intermediary non-buildable states.

which degrades or kills the value of tools like git blame, cherry-pick and bisect
egit-dev mailing list
To unsubscribe from this list, visit

Back to the top