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