lack of reviewers

[Simon Thum]

Hi all,

I would like to tell another story, perhaps you follow me.

I work on a project with a quite sharp gradient of competence in the 
development team. We do use gerrit and a build server which verifies our 
patches.

The effect of gerrit - in our case! - is to encourage the less 
knowledgeable people to do more complicated changes because they can 
rely on the infrastructure to catch most errors for them. Also, we all 
sleep better knowing it's hard to break the thing.

Gerrit discerns "review" from humans from "validation" e.g. from 
tinderbox. Every patch is validated independently, as far as is 
possible. You know pretty fast when and where you made a mistake. Also 
it will email you (configurable at the user level!) so you don't need to 
check it actively if you don't like.

For us it pays. But it also costs:

The build process and unit testing has to be handled more rigid. We have 
a lot of surrounding infrastructure just to nail the builds and tests. 
It regularly needs attention to maintain.

All in all, I think this not really a social problem - it's a social 
problem with technological roots, meaning it can be relieved 
substantially. But it's not likely to be easy even if the tinderbox 
already exists.

HTH,

Simon


On 05/18/2012 01:14 AM, Peter Hutterer wrote:
> On Thu, May 17, 2012 at 10:39:55AM +0200, Ernst Sjöstrand wrote:
>> Hi,
>>
>> (sorry for jumping in from the outside and breaking the thread!)
>>
>> I read about this problem and wanted to offer a suggestion!
>>
>> What if you set up a Gerrit server for git.freedesktop.org? That's the
>> tool the Android OpenSource project uses among other things:
>> https://android-review.googlesource.com/
>> Perhaps if it was easier to contribute to reviewing code, more people
>> would do it more often?
>
>> It's also a very nice tool I have to say, I use it every day at work.
>> It's easy to integrate with automatic
>> testing of patchsets before they're submitted to the repository for example.
>
> tbh I doubt what we have is a tool problem. Patches are sent to the list and
> can be reviewed quite easily there (for subscribers, anyway). The issue we
> have is manpower and, more importantly, manpower of people with enough
> knowledge to judge whether a patchset has side-effects beyond the obvious.
>
> in the end, such patches tend fall on the shoulders of a few and adding
> another tool that they have to check will increase, not decrease, the
> workload for those.
>
> Cheers,
>    Peter
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>