Using Gerrit for code review in KDE

Jan Kundr√°t jkt at
Tue Sep 9 23:23:18 BST 2014

On Tuesday, 9 September 2014 21:44:25 CEST, Alexander Neundorf wrote:
> Having two different patch review systems for one project... I 
> mean, this is 
> surely not a good idea. Two places to send patches, to places to review 
> patches, two different user interfaces,

This is not a final state. To be honest, I think that having a flag-day 
migration would be even worse, so running with two competing systems for a 
while seems like the only plausible way to proceed here -- otherwise one 
has that annoying chicken-and-egg problem.

It's up to kio's and plasma-framework's maintainers to decide what they 
want in the long term. I know that it's Gerrit for trojita.git, and I 
sincerely believe that the alleged UI glitches of Gerrit are far 
outweighted by the improvements which the whole stack brings, such as 
having each changeset available as a git branch to pull from. These 
benefits will only be amplified when it's integrated with a pre-approval CI 
runs, something which is just impossible to do with RB without a ton of 
ad-hoc and fragile scripting. I will surely appreciate a system which tells 
me whether a random patch I'm about to review at least builds, or whether 
there are any regression in there.

Please note that some of the often-quoted UI and usability glitches have 
been already fixed in the version of Gerrit we're running, so I would 
strongly encourage people to actually give Gerrit a try before they dismiss 
it based on personal experience with another Gerrit instance a couple of 
years ago. Some quick instructions are at [1].

> maybe logins, ...

KDE's Gerrit accepts KDE Identity logins, of course.


With kind regards,

Trojit√°, a fast Qt IMAP e-mail client --

More information about the kde-core-devel mailing list