|Re: [jgit-dev] [egit-dev] Webmaster wants to get rid of Gerrit|
Personally I don't have a strong preference. I'm happy with both workflows.
From a community perspective, Gerrit does come with a learning curve. So "quickly" providing a PR is not easy doable. On the other hand, JGit itself is not a framework one "quickly" provides a PR. However, last time I worked with a contributor he gave up and I ended up implementing the change myself. This wasn't JGit but EGit.
Another thing to consider is the future of the Eclipse project. It looks like it's moving away from Gerrit. In that case, it would hurt EGit additionally because contributors with Eclipse contribution knowledge will no longer have Gerrit experience.
The third thing to consider is the niche of Gerrit. You can probably pull some numbers of how many external contributors were there. I think JGit's decision can be done by prioritizing the wish of the existing committer base over Gerrit's on-boarding costs of new contributors. For EGit I think it's more tough.
In any case, if the decision is to continue with Gerrit I strongly recommend selecting a managed site/instance. Running our own instance on a server is not something I would like to see.
Is GerritForge the company behind http://gerrithub.io/? It seems that Gerrithub.io could be the answer to the dilemma I described above.
Back to the top