Using Gerrit for code review in KDE
Aaron J. Seigo
aseigo at kde.org
Tue Sep 9 19:02:55 BST 2014
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
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
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
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