[Intel-gfx] Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)

[alexander.levin at verizon.com]

On Tue, Nov 21, 2017 at 05:55:29PM +0000, Emil Velikov wrote:
>On 21 November 2017 at 15:07,  <alexander.levin at verizon.com> wrote:
>> On Mon, Nov 20, 2017 at 11:21:52AM +0000, Emil Velikov wrote:
>>> - Document the autoselect process
>>>Information about about What, Why, and [ideally] How - analogous to
>>>the normal stable nominations.
>>>Insert reference to the process in the patch notification email.
>>
>> I agree with this one, and it'll definitely happen. The story behind
>> this is that this is all based on Julia Lawall's work which is well
>> documented in a published paper here:
>>
>>         https://urldefense.proofpoint.com/v2/url?u=https-3A__soarsmu.github.io_papers_icse12-2Dpatch.pdf&d=DwIBaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=fv1wuXCQm6WYyxCaomxaGGxNXY-K4gUrTY4VOx24NXw&s=9BjAjAQOia0gDJdPjQJYuyj3vYKPJ3RXNRQaA-Y7eug&e=
>>
>> I have modified inputs and process, but it essentially is very similar
>> to what's described in that paper.
>>
>> While I have no problem with sharing what I have so far, this is
>> still very much work in progress, and things keep constantly changing
>> based on comments I receive from reviewers and Greg, so I want to
>> reach a more stable point before trying to explain things and change
>> my mind the day after :)
>>
>> If anyone is really interested in seeing the guts of this mess I
>> currently have I can push it to github, but bear in mind that in it's
>> current state it's very custom to the configuration I have, and is
>> a borderline unreadable mix of bash scripts and LUA.
>>
>> Ideally it'll all get cleaned up and pushed anyways once I feel
>> comfortable with the quality of the process.
>>
>At first I would focus on What and Why. Getting that information out
>and publicising it via that blogs, G+, meetings, etc. is essential.
>Reference to the current [WIP or not] heuristics is nice but can
>follow-up in due time. A placeholder must be available though.

I ended up getting a few more requests to dig into this, and I'm
always happy to get more eyes on it, so I'll clean it up slightly and
push whatever code I have to github and let anyone who wants see how
it works and improve it.

Should be done shortly after the upcoming holiday :)

>>> - Make the autoselect nominations _more_ distinct than the normal stable ones.
>>>Maintainers will want to put more cognitive effort into the patches.
>>
>> So this came up before, and the participants of that thread agreed
>> that adding "AUTOSEL" in the patch prefix is sufficient. What else
>> would you suggest adding?
>>
>Being consistent [with existing stable nominations style] is good, but
>first focus* should be on making it noticeable and distinct.
>In other words - do _not_ be consistent.
>
>Flipping the order AUTOSEL PATCH, using WARN, NOTE or just dropping
>PATCH should help.
>People tend to read PATC..... /xx: ... last words of commit message.
>
>Additionally, different template + a big note/warning in the email
>body is a good idea. Say:
>WARNING: This patch is nominated via the autosel procedure as defined at $ref.
>
>HTH
>Emil
>
>* Regardless if autosel patches default to "ACK to merge" or not.

I really didn't want to mess with the usual patch tagging ("[PATCH*")
since I'm afraid it'll interfere with people's mail rules (it would,
at least, in my case) and may cause people to miss this mail.

-- 

Thanks,
Sasha