lack of reviewers

[Maarten Maathuis]

On Fri, May 18, 2012 at 1:17 PM, Michal Suchanek <hramrach at gmail.com> wrote:
> On 18 May 2012 12:40, Peter Hutterer <peter.hutterer at who-t.net> wrote:
>> 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.
>
> Given that reviewer bandwidth is scarce it would be perhaps helpful to
> spare it by having a tool that presents all the not-yet-reviewed
> patches in one place rather than reviewers fishing for them in the
> mailing list or in the patchwork.
>
>>
>> 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.
>
> When you get the 5th patch for the same regression submitted the third
> time it starts to look like shouting your patches off a cliff in the
> dead of the night.
>
>
>>
>>
>>> - 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.
>
> And as some of the patches get replies they get out of order and
> completely out of context.
>
>>
>>
>>> - 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?
>
> Like a series of 10+ patches for some part of the X server I do not
> understand landing on the list several times.
>
> I guess some people are fond of replying to the patches and quoting
> them in their email client and I can see that as nice feature but it's
> paid for by tons of list traffic. Necessarily large part of that is
> meaningless to most.
>
> The alternative is, of course, a link to git branch or something like that.
>
> Thanks
>
> Michal
> _______________________________________________
> 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

I think that a tool that allows you to see diffs in a web interface
and do point-and-click defect submission would never hurt. As long as
it doesn't interfere with existing processes (too much).

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.