Using Gerrit for code review in KDE
bcooksley at kde.org
Tue Sep 9 19:54:50 BST 2014
Just to clarify what is happening here, based on my reading of the
discussion here thus far, and in #kde-devel earlier today.
I concur with the majority that a unified tool, similar to Gitlab
would be an excellent improvement on our current infrastructure.
Unfortunately we found that at one point Gitlab contained code to
email debug data to a given address. This is an unacceptable security
issue. While it has since been removed as far as we are aware, it
makes it impossible to trust the software, particularly considering we
are trusting it with the canonical copy of our Git repositories. It
also has issues with groups (requiring us to keep them in sync
manually), has undesirable behaviour when moving repositories (sends
an email to every member of the group - so 2000+) and requires us to
hack the software in order to integrate our own hooks.
In regards to Phabricator - we have examined this in the past as a
replacement for projects.kde.org. While generally impressed with it's
performance, it still lacked the per-revision code review tools that
people are after which Gerrit provides. It also relied on special
capitalised names for each repository which are supposed to be a
shortcut to them. Considering we have more than 600 repositories, we
would need to use their full names here - which would lead to fairly
We have yet to have time to evaluate Gogs.io.
In regards to why we are permitting Gerrit to be evaluated - it is
primarily to allow for the community to come to a decision. The
complexity of the user interface among other issues are still problems
which sysadmin believes could block it's overall adoption.
I had hoped that independent projects, rather than Frameworks or
anything along those lines would be the test subjects in this case
More information about the kde-core-devel