Using Gerrit for code review in KDE

[Aaron J. Seigo]

On Tuesday, September 9, 2014 18.49:24 Kevin Ottens wrote:
> > As it stands with plasma-framework in particular, there is now a
> > difference
> > in workflow depending on what *part* of plasma one is working on
> > (framework
> > or workspace). So not only is it now different from the majority of
> > frameworks, it is also "different from itself".
> 
> It was focused on KF5, but if Plasma people feel like having all the related
> repositories part of the experiment they could decide it but...

That would honestly make more sense for Plasma imho, though it still would 
make sense to start small and consistent.

> People at the meeting picked those two because it was deemed desirable to
> avoid using something small or not too active to find the pain points. I
> think it makes sense. For something which seldom get patches it's unlikely
> we'll have enough information for later decision.
[...]
> ... the experiment is not about Gerrit vs Gitolite + ReviewBoard. It is
> Gerrit in addition to Gitolite + ReviewBoard. In that sense it is very
> different from the earlier GitLab experiment. Also it is completely opt-in
> for developers when they submit patches.

Which makes it more chaotic / less predictable. I'm failing to understand how 
that's desirable. It seems the opposite of the craftsmanship you have been 
advocating.

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.

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.

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? Why go straight for stable, releasing frameworks?

They could put *all* of their patches through gerrit and see how a 100% gerrit 
project feels. They are all actively developed but not core frameworks.

> 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 and a 
reasonable measure of project-follows-documented-processes.

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.

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

-- 
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/20140909/2d7a757c/attachment.sig>