That said there are known negatives; the Java+Google Web Toolkit >front-end
is intimidating to people who might want to help improve >the UI; even Gerrit devs don't love it. :)
Improvements to the UI and to the git-review CLI tool are welcome...
Intimidating to PHP+JS only devs - but Java+Google Web Toolkit is this systems second iteration for Gerrit. I think that it would be possible to add all the changes we need into Gerrit, I personally feel more comfortable hacking Gerrit which has an upstream and a community than our previous code review plug-in which had none. A large number of our issues are already being added by the Gerrit community and by Chad. However the comment above clearly highlight an issue arising from running an almost exclusively PHP+JS shop and under adoption of FOSS development methodologies
That being said:
Using FOSS tools has a higher total cost of ownership. Managers who authorized a switch from a working system (SVN/Code review) to a new and immature systems such as Git/Gerrit - should have set aside resources (time & money) to offset the problems created by such migrations.
These generally amount to several orders of magnitude of the actual cost of the migration done by operations. The bulk of the work created by these changes are offset to the individual developers whose project will be broken by change of workflow and who might not be active. It passing strange how few of the extensions are under-maintained, unsupported.
For example: * Integration of Gerrit to our system, * Customization (adding features like better diffs) * Acceptance - getting people to change workflow and getting core developers to actually review code. * Education - Teaching established and new users to work with the Git/Gerrit, writing tutorials, training people with them at Hackatons. Updating project documentations and readmes * Secondary migration - fixing scripts/apis that depend on the current setup. E.g. my CI work in December needs to be updated to reflect using GIT/Gerrit; build scripts of systems with independent modules like search + mwdumper; updating robots and so on. * Tertiary migrations - On the developers machines. Replacing IDEs and Workspaces to reflect the Git/Gerrit workflows.
Thus switching forth between different Gerrit alternative is myopic. It ignores the friction and cost these moves create for the established developers community who have created hundreds of extensions and documented them. I say we just get consensus on the Priority Queue of outstanding Gerrit issues and start fix them until it rocks.
Oren Bochman Lead of Search