[Mesa-dev] Adaptive Vsync

[Albert Freeman]

Correction, we just need someone to mark all the comitted patches in
patchwork so that we can easily pick out the ones with issues.

On 7 September 2015 at 04:56, Albert Freeman <albertwdfreeman at gmail.com> wrote:
> 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