Using Gerrit for code review in KDE
Jan Kundrát
jkt at flaska.net
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.
[1] https://techbase.kde.org/Development/Gerrit
With kind regards,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
More information about the kde-core-devel
mailing list