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 12.11.21 23:41 , Matthias Sohn wrote:

Hi,

webmaster opened the issue
https://bugs.eclipse.org/bugs/show_bug.cgi?id=577152
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:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=577153

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:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=577151

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'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.

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.

Perhaps gerrithub might be an option?

But the larger issue is that moving elsewhere probably also means moving
the CI build infrastructure elsewhere. 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
non-free.

(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?

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.

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?

Cheers,

  Thomas

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.

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.

Back to the top