Using Gerrit for code review in KDE

[Aaron J. Seigo]

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 
practice.

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, 
documentation, etc.

anyways .. i've said my bit, so EOT for me :) cheers ...

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20140910/c9c82d8b/attachment.sig>