lack of reviewers

[Peter Hutterer]

On 18/05/12 19:26 , Michal Suchanek wrote:
> On 18 May 2012 01:14, Peter Hutterer<peter.hutterer at who-t.net>  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.
>
> tbh using a mailing list for that looks very impractical.
>
> - patches get missed completely

true. we do encourage people to re-submit. which, aside from the obvious 
disadvantage, has advantages too. I found the problem with any todo list 
is that sooner or later it becomes so long that you either have to wipe 
it (by switching to a different system sometimes) or you start ignoring 
stuff anyway.

given that one of the problems is reviewer bandwidth, I expect this to 
happen with any new tool. patchwork was great in the first few weeks, 
now it's a kitchensink great for getting URLs and not much else.

requiring people to ping when patches get missed at least notifies us 
which patches have people behind them that care. a feature that gets 
submitted once, forgotten and no-one pings for it may not have been that 
important to begin with.

> - there is no track of what is related to what (as in the part of the
> same patchset or new revision of the same patchset)

patch are usually in numbered series, in threads, with new revisinos 
being prefixed with "v2", "v3", etc. requires submitter discipline but 
it works to some degree.

> - you get a lots of list noise due to patches being sent one by one

I'm not sure I follow this argument, can you expand?

don't get me wrong, I don't think mailing lists is the ideal approach 
but I haven't seen a better one. it is an old approach and many people 
are well set up for the workflow so any new tool will have to have meet 
quite a threshold there.

Cheers,
   Peter