Using Gerrit for code review in KDE
Aaron J. Seigo
aseigo at kde.org
Wed Sep 10 09:50:22 BST 2014
On Wednesday, September 10, 2014 00.23:18 Jan Kundrát wrote:
> 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.
talking about a migration, "flag-day" or otherwise, before proving runs have
been done is premature.
this seems to be at the test-it-out stage, and as such it would be nice to see
it not disrupt extant and documented workflow. imagine the disruption that
would ensue if we took this approach for every experiment that alters extant
i understand you are a great advocate for gerrit, and that's cool; but please
bring it into kde with respect for the big picture and do so with
responsibility. i think you'll find it a lot easier to convince people it is a
good idea if there is a measured, responsible approach applied.
> Please note that some of the often-quoted UI and usability glitches have
it really has very little to do with how good gerrit is. gerrit can be the
messiah sent from on high, but continuity in development processes across the
community is even more important. there are ways to introduce workflow
improvements, and the options vary depending on whether there is precedent,
anyways .. i've said my bit, so EOT for me :) cheers ...
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel