Using Gerrit for code review in KDE

[Kevin Ottens]

On Tuesday 09 September 2014 20:02:55 Aaron J. Seigo wrote:
> In any case, can you see the inconsistency between saying "we need highly
> active repos to find pain points" and "these projects will only use it on an
> opt-in basis, and not even for all patches"? You may as well throw a more
> lightly developed repository at it all-in to get that same level of
> activity. Either that or kio and plasma-framework will go all-in and then
> it is exactly like the gitlab experiment. You really can't argue it both
> ways.

OK, let me put it differently I would expect (I obviously don't control them 
though) the core contributors of those two frameworks to go all in for a 
while. Where I see a difference is that during the time of experiment it will 
leave the other less committed contributors undisturbed.

> A reasonable project of a 3-5 active developers who are doing 2-3 patch sets
> a week ought to give one all the data set necessary. One can extrapolate
> from such a sample pretty easily. I know I managed to do it with gitlab and
> there wasn't even that level of activity.

I agree that makes sense too. Now there was a will in the room of trying out 
with a couple of frameworks. Right now we seem to be in a phase active vs 
almost inactive, so people chose two active ones.

> So as I asked, are there any actively developed repos that aren't *as*
> critical and part of major stable releases? That ought to be a rhetorical
> question as I can think of probably half a dozen off the top of my head. How
> about that new video player that was demo'd at akademy? How about
> kde-connect? How about the plasma-desktop repository, if the plasma team
> really wants to try it out?

Sure, all valid ones to try with IMO.

> Why go straight for stable, releasing frameworks?

Basically the topic was brought up to that particular BoF by Jan which in turn 
prompted the "OK, this installation is low risk, let's try with two frameworks 
to test the water". Part of the reasoning there has also been "the tool might 
give us further ideas on our branch policies", since there's some KF specific 
decisions around those due to the one month cycle it was considered to make 
sense to have KF part of the experiment.

> > I then doubt it would be a problem for new developers. The only thing they
> > would "loose" by default is the knowledge of some of the patches cooking
> > up in Gerrit when the team tests it. But I would be surprised if the
> > majority of new developers actively look at the list of patches prepared
> > in RB either.
> 
> I'd think about the will-be-long-term-active minority for which one ought to
> keep the barrier to entry low which includes consistency in tooling

Agreed, but that's where I don't follow you. Those one shouldn't see a 
difference in the barrier of entry during the experiment.

> and a reasonable measure of project-follows-documented-processes.

That I can agree with that indeed for a limited time some people in the 
project will go through a specific review tool. That said our policies in KF 
ask for reviews, they don't mandate a particular tool. It was done to open the 
door to reviews by email and pastebin. It is no different IMO.

> I'd also think about the developers who follow those reviews now and who
> will now have to pay attention to multiple tools to keep up.

Those were in the room and willing to pay that price for the time of the 
experiment.

> I'm all for improvements through change, but one can minimize disruptions as
> they go.

Sure. Still I fail to perceive a large disruption in that case. I'd agree if 
we said "OK, all contributions to kio go through Gerrit now", we're saying 
"during the time of the experiment core devel contributions to kio go through 
Gerrit, everything else is business as usual".

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com

-------------- 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/6818e61e/attachment.sig>