[Mesa-dev] Adaptive Vsync

[Albert Freeman]

Oops, my "plan" focuses on patches that have nothing wrong with them,
instead of patches that have something wrong with them (which is the
problem). It is lack of reviews, not lack of commits. I have no idea
how I got so confused. Basically we need the inverse of patchwork.

On 6 September 2015 at 11:42, Albert Freeman <albertwdfreeman at gmail.com> wrote:
> Ah, okay. I see what you mean now (i.e. you had to wait three months
> for those suggestions I mentioned). I still haven't recieved a
> response at all for my first patch from almost a year ago (although it
> was insanely trivial). So it isn't just you :)
>
> Committers simply don't have the time to find every patch.
>
> From what I can see, this is due to the fact that the current "mailing
> list model" does not really provide an easy way for committers to know
> when something actually should be committed. Patches sometimes have
> reviewed by lines that would require AI to analyse properly (basically
> making automation impractical) (e.g. suggested changes of reviewer
> followed by reviewed by line - while in other cases just the reviewed
> by line).
>
> Plan "draft":
> We need more meaningful patch response tags.
> Some way to assign "review power" based on email address.
> A policy deciding when a patch is ready (based on response tags and
> "review power").
> Some way to parse the entire mesa mailing list and send all the
> patches that meet criteria to the committer.
>
> Three problems:
> 1. I can't implement this with my current email and/or scripting knowledge.
> 2. We can't just automatically commit patches for security reasons
> (best not to mention).
> 3. Whether committers would even like to make any changes.
>
> On 6 September 2015 at 08:28, Lauri Kasanen <cand at gmx.com> wrote:
>> On Sat, 5 Sep 2015 23:29:05 +0000
>> Albert Freeman <albertwdfreeman at gmail.com> wrote:
>>
>>> The reply from Eric Anholt made two suggestions that should not be
>>> difficult to implement for someone who made the patch in the first
>>> place. Why would code be committed when improvements could be easily
>>> made? From what I have seen, this kind of thing happens even to
>>> experienced mesa developers who know exactly what they are doing.
>>>
>>> It is much better to arrive at a solution without the issue now than
>>> wait a few years (or some other period of time) for it to be replaced
>>> by someone who has likely forgotten the details involved with its
>>> implementation (or by someone who did not write the code in the first
>>> place).
>>
>> Oh, absolutely - I had no issues with "this needs changing". My issue
>> was with the fact it took months to get that. Had I come up with a new
>> patch, it would likely have taken a similar time, months again, which
>> did not inspire confidence.
>>
>> Benjamin, if you want to take it forward, please do.
>>
>> - Lauri