Using Gerrit for code review in KDE

Eike Hein hein at
Sat Sep 13 19:38:21 BST 2014

On 13.09.2014 17:49, Martin Gräßlin wrote:
> my understanding was that it's still possible to bypass the code review, so I
> cannot see that it's against the KDE Manifesto as it's only a kind of social
> contract. Or am I missing something.
> Personally I like the idea of having the +2 limited to the devs familiar with
> the code.

I *strongly* disagree with and even object to this.

One of the biggest achievements of the KDE community is having
become multi-generational and turnover-proof, whereas most pro-
jects peter out when their initial developer generation moves
on. Note how few people in this thread were around in 1998.

I attribute this to a few traits of our structure:

* Flat hierarchies and few, mostly informally held titles.

* Broad, equal write access.

* Encouraging people to feel responsible for what we make.

These things reinforce each other in multiple ways. If main-
tainers are not entrenched positions, they're easy to replace
when they move on (whether they can accept this themselves or
not). Once you codify them in ACLs (and yes, we do this in
some places already, and I think this was a mistake as well)
you add inertia because those ACLs need to be updated, and
someone needs to work up the gumption to ask for that update.

(Case study of what can happen when we lose track of this:
We lost KDM. There are many more positive case studies where
contributors kept projects alive once maintainers disappeared
just by slowly ramping up their involvement, without needing
"hand over the keys" flag days.)

If maintainers aren't entrenched, you also can't rely on them
picking up the slack; hence encouraging stepping up.

How do you become a maintainer? By actively doing review,
for one. I.e. it's up to *maintainers* to stay active and
involve themselves in the process, and provide guidance so
that good code goes in and bad code stays out. The safety
net we have for review working is our brains when making
or picking through arguments.

The argument "but you can still bypass Gerrit and push
directly, this is just social etiquette" doesn't matter
because the whole thing is about social etiquette. The
ACLs we already have reflect our social etiquette, and
that means we need to be careful and think smart about
evolving it.

Personally I think social etiquette encouraging the use
of review tools is fine. Social etiquette that entrenches
some developers as special on those review tools is not.


More information about the kde-core-devel mailing list