Re: 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]

On Tue, Nov 21, 2017 at 05:55:29PM +, Emil Velikov wrote:
>On 21 November 2017 at 15:07,   wrote:
>> On Mon, Nov 20, 2017 at 11:21:52AM +, 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=DwIBaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo=fv1wuXCQm6WYyxCaomxaGGxNXY-K4gUrTY4VOx24NXw=9BjAjAQOia0gDJdPjQJYuyj3vYKPJ3RXNRQaA-Y7eug=
>>
>> 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

Re: 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]

On Tue, Nov 21, 2017 at 05:55:29PM +, Emil Velikov wrote:
>On 21 November 2017 at 15:07,   wrote:
>> On Mon, Nov 20, 2017 at 11:21:52AM +, 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=DwIBaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo=fv1wuXCQm6WYyxCaomxaGGxNXY-K4gUrTY4VOx24NXw=9BjAjAQOia0gDJdPjQJYuyj3vYKPJ3RXNRQaA-Y7eug=
>>
>> 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

Re: 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]

On Tue, Nov 21, 2017 at 12:09:33PM -0500, Josh Boyer wrote:
>The root of the concern seems to be around how the stable process
>currently works and how auto-selection plays into that.  When Greg
>sends out the RC, the default model of "if nobody objects, this patch
>will get included in the next stable release" works because a human
>already identified as that needing to be included.  So the review is
>looking for a NAK, but that's overriding another human's explicit
>decision with reasons.  For something that is auto-selected, people
>seem concerned that the default should be flipped.  Perhaps they'd be
>more comfortable if auto-selected packages required a human ACK before
>they are included?

Josh, I review the autogenerated list of commits, patch by patch,
myself, before sending it out. So there is a human involved in the
process.

Admittingly I'm not perfect and things do slip by once in a while. I
always look back and try to improve the process. Although the sample
size is small now (~600 commits proposed and merged using this method)
I don't belive the error rate is higher than the error rate for
"regular" stable tree commits.

I'd treat autoselection as a helper tool for the stable tree
maintainer rather than a magical way to produce stable commits (we're
not going to replace Greg with a robot any time soon).

-- 

Thanks,
Sasha

Re: 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]

On Tue, Nov 21, 2017 at 12:09:33PM -0500, Josh Boyer wrote:
>The root of the concern seems to be around how the stable process
>currently works and how auto-selection plays into that.  When Greg
>sends out the RC, the default model of "if nobody objects, this patch
>will get included in the next stable release" works because a human
>already identified as that needing to be included.  So the review is
>looking for a NAK, but that's overriding another human's explicit
>decision with reasons.  For something that is auto-selected, people
>seem concerned that the default should be flipped.  Perhaps they'd be
>more comfortable if auto-selected packages required a human ACK before
>they are included?

Josh, I review the autogenerated list of commits, patch by patch,
myself, before sending it out. So there is a human involved in the
process.

Admittingly I'm not perfect and things do slip by once in a while. I
always look back and try to improve the process. Although the sample
size is small now (~600 commits proposed and merged using this method)
I don't belive the error rate is higher than the error rate for
"regular" stable tree commits.

I'd treat autoselection as a helper tool for the stable tree
maintainer rather than a magical way to produce stable commits (we're
not going to replace Greg with a robot any time soon).

-- 

Thanks,
Sasha

Re: 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)

[Emil Velikov]

On 21 November 2017 at 15:07,   wrote:
> On Mon, Nov 20, 2017 at 11:21:52AM +, 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://soarsmu.github.io/papers/icse12-patch.pdf
>
> 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.

>> - 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.

Re: 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)

[Emil Velikov]

On 21 November 2017 at 15:07,   wrote:
> On Mon, Nov 20, 2017 at 11:21:52AM +, 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://soarsmu.github.io/papers/icse12-patch.pdf
>
> 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.

>> - 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.

Re: 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)

[Greg KH]

On Tue, Nov 21, 2017 at 12:09:33PM -0500, Josh Boyer wrote:
> On Tue, Nov 21, 2017 at 10:07 AM,   wrote:
> > On Mon, Nov 20, 2017 at 11:21:52AM +, 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://soarsmu.github.io/papers/icse12-patch.pdf
> >
> > 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.
> >
> >> - 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?
> 
> The root of the concern seems to be around how the stable process
> currently works and how auto-selection plays into that.  When Greg
> sends out the RC, the default model of "if nobody objects, this patch
> will get included in the next stable release" works because a human
> already identified as that needing to be included.  So the review is
> looking for a NAK, but that's overriding another human's explicit
> decision with reasons.  For something that is auto-selected, people
> seem concerned that the default should be flipped.  Perhaps they'd be
> more comfortable if auto-selected packages required a human ACK before
> they are included?

As much fun as that might be, that's going to cut _way_ down on the
number of real bugfixes that get applied to the kernel due to the lag in
responses.  I review all of these patches, as does Sasha, so I think
let's stick with the existing mode of "it passes our review so let's
include it".  Becides, the testing that everyone is doing on the stable
kernels should catch any real problems, right?  :)

But if any subsystems don't want us to include patches this way, just
let us know.  It seems the graphics developers don't want their patches
backported, which is fine, we will leave them alone...

thanks,

greg k-h

Re: 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)

[Greg KH]

On Tue, Nov 21, 2017 at 12:09:33PM -0500, Josh Boyer wrote:
> On Tue, Nov 21, 2017 at 10:07 AM,   wrote:
> > On Mon, Nov 20, 2017 at 11:21:52AM +, 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://soarsmu.github.io/papers/icse12-patch.pdf
> >
> > 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.
> >
> >> - 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?
> 
> The root of the concern seems to be around how the stable process
> currently works and how auto-selection plays into that.  When Greg
> sends out the RC, the default model of "if nobody objects, this patch
> will get included in the next stable release" works because a human
> already identified as that needing to be included.  So the review is
> looking for a NAK, but that's overriding another human's explicit
> decision with reasons.  For something that is auto-selected, people
> seem concerned that the default should be flipped.  Perhaps they'd be
> more comfortable if auto-selected packages required a human ACK before
> they are included?

As much fun as that might be, that's going to cut _way_ down on the
number of real bugfixes that get applied to the kernel due to the lag in
responses.  I review all of these patches, as does Sasha, so I think
let's stick with the existing mode of "it passes our review so let's
include it".  Becides, the testing that everyone is doing on the stable
kernels should catch any real problems, right?  :)

But if any subsystems don't want us to include patches this way, just
let us know.  It seems the graphics developers don't want their patches
backported, which is fine, we will leave them alone...

thanks,

greg k-h

Re: 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)

[Josh Boyer]

On Tue, Nov 21, 2017 at 10:07 AM,   wrote:
> On Mon, Nov 20, 2017 at 11:21:52AM +, 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://soarsmu.github.io/papers/icse12-patch.pdf
>
> 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.
>
>> - 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?

The root of the concern seems to be around how the stable process
currently works and how auto-selection plays into that.  When Greg
sends out the RC, the default model of "if nobody objects, this patch
will get included in the next stable release" works because a human
already identified as that needing to be included.  So the review is
looking for a NAK, but that's overriding another human's explicit
decision with reasons.  For something that is auto-selected, people
seem concerned that the default should be flipped.  Perhaps they'd be
more comfortable if auto-selected packages required a human ACK before
they are included?

josh

Re: 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)

[Josh Boyer]

On Tue, Nov 21, 2017 at 10:07 AM,   wrote:
> On Mon, Nov 20, 2017 at 11:21:52AM +, 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://soarsmu.github.io/papers/icse12-patch.pdf
>
> 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.
>
>> - 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?

The root of the concern seems to be around how the stable process
currently works and how auto-selection plays into that.  When Greg
sends out the RC, the default model of "if nobody objects, this patch
will get included in the next stable release" works because a human
already identified as that needing to be included.  So the review is
looking for a NAK, but that's overriding another human's explicit
decision with reasons.  For something that is auto-selected, people
seem concerned that the default should be flipped.  Perhaps they'd be
more comfortable if auto-selected packages required a human ACK before
they are included?

josh

Re: 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]

On Mon, Nov 20, 2017 at 11:21:52AM +, 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://soarsmu.github.io/papers/icse12-patch.pdf

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.

> - 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?

-- 

Thanks,
Sasha

Re: 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]

On Mon, Nov 20, 2017 at 11:21:52AM +, 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://soarsmu.github.io/papers/icse12-patch.pdf

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.

> - 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?

-- 

Thanks,
Sasha

Re: [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)

[Daniel Vetter]

On Tue, Nov 21, 2017 at 07:39:51AM +1000, Dave Airlie wrote:
> On 20 November 2017 at 23:13, Daniel Vetter  wrote:
> > On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote:
> >> On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote:
> >> > Hi all,
> >> >
> >> > Since I'm going slightly off-topic, I've tweaked the subject line and
> >> > trimmed some of the conversation.
> >> > I believe everyone in the CC list might be interested in the
> >> > following, yet feel free to adjust.
> >> >
> >> > Above all, I'd kindly ask everyone to skim through and draw their 
> >> > conclusions.
> >> > If the ideas put forward have some value - great, if not - let my email 
> >> > rot.
> >> >
> >> > On 17 November 2017 at 13:57, Greg KH  wrote:
> >> >
> >> > >>
> >> > >> I still have no idea how this autoselect picks up patches that do 
> >> > >> *not*
> >> > >> have cc: stable nor Fixes: from us. What information do you have that 
> >> > >> we
> >> > >> don't for making that call?
> >> > >
> >> > > I'll let Sasha describe how he's doing this, but in the end, does it
> >> > > really matter _how_ it is done, vs. the fact that it seems to at least
> >> > > one human reviewer that this is a patch that _should_ be included based
> >> > > on the changelog text and the code patch?
> >> > >
> >> > > By having this review process that Sasha is providing, he's saying
> >> > > "Here's a patch that I think might be good for stable, do you object?"
> >> > >
> >> > > If you do, great, no harm done, all is fine, the patch is dropped.  If
> >> > > you don't object, just ignore the email and the patch gets merged.
> >> > >
> >> > > If you don't want any of this to happen for your subsystem at all, then
> >> > > also fine, just let us know and we will ignore it entirely.
> >> > >
> >> > Let me start with saying that I'm handling the releases for Mesa 3D -
> >> > the project providing OpenGL, Vulkan and many other userspace graphics
> >> > drivers.
> >> > I've been doing that for 3 years now, which admittedly is quite a
> >> > short time relative to the kernel.
> >> >
> >> > There is a procedure quite similar to the kernel, with a few
> >> > differences - see below for details.
> >> > We also autoselect patches, hence my interest in the heuristics
> >> > applied for nominating patches ;-)
> >> >
> >> > That aside, here are some things I've learned from my experience.
> >> > Some of those may not be applicable - hope you'll find them useful:
> >> >
> >> >  - Try to reference developers to existing documentation/procedure.
> >> > Was just reminded that even long standing developers can forget detail X 
> >> > or Y.
> >> >
> >> >  - CC developers for the important stuff - aka do not CC on each 
> >> > accepted patch.
> >> > Accepted patches are merged in pre-release branch and a email with
> >> > accepted/deferred/rejected list is sent.
> >> > Patches that had conflicts merging, and ones that are rejected have
> >> > their author in the CC list.
> >> > Rejected patches have brief description + developers are contacted 
> >> > beforehand.
> >> >
> >> >  - Autoselect patches are merged only with the approval from the
> >> > respective developers.
> >> > IMHO this engages developers into the process, without distracting
> >> > them too much.
> >>
> >> Getting explicit confirmation for autoselected patches sounds like a very
> >> good idea to me. We intentionally limit the amount of patches we cc:
> >> stable, because we simply don't have the manpower around to support stable
> >> fully (i.e. with proper CI and everything). And less backported patches
> >> means fewer regressions, which is more important than fixing someone
> >> else's bug.
> >>
> >> Of course our CI is open, so if someone is supremely bored and wants to
> >> backport more stuff for drm/i915, they could do that. But atm it doesn't
> >> happen, and then having to deal with the fallout is not really great (like
> >> I said, we don't really have anyone dedicated, and I much prefer we
> >> fix/improve upstream).
> >>
> >> For the actual products we're shipping we have dedicated teams doing the
> >> backports. The upstream stable releases essentially have no value for us
> >> from a customer support pov (for drivers, I guess core stuff is an
> >> entirely different matter), there's not a single serious customer or
> >> bigger user using that. It only costs, by spamming us with mails and bug
> >> reports for stuff we didn't even nominate :-)
> >>
> >> Just my 2 cents here, but I think this perpespective matches with other
> >> big drm drivers like amdgpu (I just discussed this exact topic of how
> >> upstream stable is useless with Alex).
> >
> > Just to clarify, this includes non-(directly-)paying customers like 
> > community
> > distros: Either they track the quarterly releases (of both the kernel and
> > userspace) because they care about the latest gpu driver work. Or they
> > want LTS and stability uber alles, and in 

Re: [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)

[Daniel Vetter]

On Tue, Nov 21, 2017 at 07:39:51AM +1000, Dave Airlie wrote:
> On 20 November 2017 at 23:13, Daniel Vetter  wrote:
> > On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote:
> >> On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote:
> >> > Hi all,
> >> >
> >> > Since I'm going slightly off-topic, I've tweaked the subject line and
> >> > trimmed some of the conversation.
> >> > I believe everyone in the CC list might be interested in the
> >> > following, yet feel free to adjust.
> >> >
> >> > Above all, I'd kindly ask everyone to skim through and draw their 
> >> > conclusions.
> >> > If the ideas put forward have some value - great, if not - let my email 
> >> > rot.
> >> >
> >> > On 17 November 2017 at 13:57, Greg KH  wrote:
> >> >
> >> > >>
> >> > >> I still have no idea how this autoselect picks up patches that do 
> >> > >> *not*
> >> > >> have cc: stable nor Fixes: from us. What information do you have that 
> >> > >> we
> >> > >> don't for making that call?
> >> > >
> >> > > I'll let Sasha describe how he's doing this, but in the end, does it
> >> > > really matter _how_ it is done, vs. the fact that it seems to at least
> >> > > one human reviewer that this is a patch that _should_ be included based
> >> > > on the changelog text and the code patch?
> >> > >
> >> > > By having this review process that Sasha is providing, he's saying
> >> > > "Here's a patch that I think might be good for stable, do you object?"
> >> > >
> >> > > If you do, great, no harm done, all is fine, the patch is dropped.  If
> >> > > you don't object, just ignore the email and the patch gets merged.
> >> > >
> >> > > If you don't want any of this to happen for your subsystem at all, then
> >> > > also fine, just let us know and we will ignore it entirely.
> >> > >
> >> > Let me start with saying that I'm handling the releases for Mesa 3D -
> >> > the project providing OpenGL, Vulkan and many other userspace graphics
> >> > drivers.
> >> > I've been doing that for 3 years now, which admittedly is quite a
> >> > short time relative to the kernel.
> >> >
> >> > There is a procedure quite similar to the kernel, with a few
> >> > differences - see below for details.
> >> > We also autoselect patches, hence my interest in the heuristics
> >> > applied for nominating patches ;-)
> >> >
> >> > That aside, here are some things I've learned from my experience.
> >> > Some of those may not be applicable - hope you'll find them useful:
> >> >
> >> >  - Try to reference developers to existing documentation/procedure.
> >> > Was just reminded that even long standing developers can forget detail X 
> >> > or Y.
> >> >
> >> >  - CC developers for the important stuff - aka do not CC on each 
> >> > accepted patch.
> >> > Accepted patches are merged in pre-release branch and a email with
> >> > accepted/deferred/rejected list is sent.
> >> > Patches that had conflicts merging, and ones that are rejected have
> >> > their author in the CC list.
> >> > Rejected patches have brief description + developers are contacted 
> >> > beforehand.
> >> >
> >> >  - Autoselect patches are merged only with the approval from the
> >> > respective developers.
> >> > IMHO this engages developers into the process, without distracting
> >> > them too much.
> >>
> >> Getting explicit confirmation for autoselected patches sounds like a very
> >> good idea to me. We intentionally limit the amount of patches we cc:
> >> stable, because we simply don't have the manpower around to support stable
> >> fully (i.e. with proper CI and everything). And less backported patches
> >> means fewer regressions, which is more important than fixing someone
> >> else's bug.
> >>
> >> Of course our CI is open, so if someone is supremely bored and wants to
> >> backport more stuff for drm/i915, they could do that. But atm it doesn't
> >> happen, and then having to deal with the fallout is not really great (like
> >> I said, we don't really have anyone dedicated, and I much prefer we
> >> fix/improve upstream).
> >>
> >> For the actual products we're shipping we have dedicated teams doing the
> >> backports. The upstream stable releases essentially have no value for us
> >> from a customer support pov (for drivers, I guess core stuff is an
> >> entirely different matter), there's not a single serious customer or
> >> bigger user using that. It only costs, by spamming us with mails and bug
> >> reports for stuff we didn't even nominate :-)
> >>
> >> Just my 2 cents here, but I think this perpespective matches with other
> >> big drm drivers like amdgpu (I just discussed this exact topic of how
> >> upstream stable is useless with Alex).
> >
> > Just to clarify, this includes non-(directly-)paying customers like 
> > community
> > distros: Either they track the quarterly releases (of both the kernel and
> > userspace) because they care about the latest gpu driver work. Or they
> > want LTS and stability uber alles, and in that case being aggressive with
> > backporting 

Re: 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)

[Daniel Vetter]

On Tue, Nov 21, 2017 at 08:58:51AM +0100, Greg KH wrote:
> On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote:
> > Of course our CI is open, so if someone is supremely bored and wants to
> > backport more stuff for drm/i915, they could do that. But atm it doesn't
> > happen, and then having to deal with the fallout is not really great (like
> > I said, we don't really have anyone dedicated, and I much prefer we
> > fix/improve upstream).
> 
> Any reason you can't add the stable -rc tree to your CI system?

The problem is looking at results and making sure nothing breaks and
sending mails out that patches shouldn't be applied and all that. Keeping
the machines busy is the easy part.

For Linus' -rc/-fixes we do that (including human review of all the stuff
the scripts suggests we need to cherry-pick as fixes), but that's because
we have someone.

Maybe we can/should look into doing the same for the current stable (to
support fedora and other community distros a bit better). But I think
there's no way we can support all the LTS kernels out there and more than
just minimal backports.

> > For the actual products we're shipping we have dedicated teams doing the
> > backports. The upstream stable releases essentially have no value for us
> > from a customer support pov (for drivers, I guess core stuff is an
> > entirely different matter), there's not a single serious customer or
> > bigger user using that. It only costs, by spamming us with mails and bug
> > reports for stuff we didn't even nominate :-)
> 
> Any reason why you aren't sending those backported patches to the stable
> trees so that users of them can benefit from the work you are already
> doing for a limited number of "customers"?

They fail your backporting criteria. Big time, like veeery big time.

Think backporting 1k patches to get some feature. Which then means it's a
frankenkernel without any relation to any shipping stable drm/i915
release, so the backports of the bugfixes are again meaningless and
untested for anything else.

Tbh the easies for us to support is what rhel does for their updates,
which is just copy all of drivers/gpu/ into their old lts kernel and then
fix things up at the seams.

> And if your customers are not using stable kernel releases, what are
> they using for their kernels?

LTS, but with a frankenstein drm/i915. To clarify, all I'm discussing here
is just drm and drm/i915 patches, I think for core code the stable process
works reasonably well (afaiui at least).

> It sounds like you don't want to deal with the "automated" patches for
> the i915 drivers, so that's fine, we will blacklist them and ignore
> them and only deal with the patches you explicitly ask to be backported.
> As it seems like those are hard enough for you all to deal with, given
> the recent regression :)

Yeah that would at least not make it worse.

On the entire problem (that we share with amd folks, see Alex' reply) of
how to ship gpu kernel driver updates to people who care, but don't want
to track latest upstream releases, I'd love to have a solution. I just
don't see one (except tons of manual backport work).

Fundamentally the problem is that the product freeze cycle for core kernel
code (measured in years often) is just plain unsuitable for gfx drivers
(where in userspace we often end up shipping well-tested points from
master because the quarterly releases are too slow).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: 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)

[Daniel Vetter]

On Tue, Nov 21, 2017 at 08:58:51AM +0100, Greg KH wrote:
> On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote:
> > Of course our CI is open, so if someone is supremely bored and wants to
> > backport more stuff for drm/i915, they could do that. But atm it doesn't
> > happen, and then having to deal with the fallout is not really great (like
> > I said, we don't really have anyone dedicated, and I much prefer we
> > fix/improve upstream).
> 
> Any reason you can't add the stable -rc tree to your CI system?

The problem is looking at results and making sure nothing breaks and
sending mails out that patches shouldn't be applied and all that. Keeping
the machines busy is the easy part.

For Linus' -rc/-fixes we do that (including human review of all the stuff
the scripts suggests we need to cherry-pick as fixes), but that's because
we have someone.

Maybe we can/should look into doing the same for the current stable (to
support fedora and other community distros a bit better). But I think
there's no way we can support all the LTS kernels out there and more than
just minimal backports.

> > For the actual products we're shipping we have dedicated teams doing the
> > backports. The upstream stable releases essentially have no value for us
> > from a customer support pov (for drivers, I guess core stuff is an
> > entirely different matter), there's not a single serious customer or
> > bigger user using that. It only costs, by spamming us with mails and bug
> > reports for stuff we didn't even nominate :-)
> 
> Any reason why you aren't sending those backported patches to the stable
> trees so that users of them can benefit from the work you are already
> doing for a limited number of "customers"?

They fail your backporting criteria. Big time, like veeery big time.

Think backporting 1k patches to get some feature. Which then means it's a
frankenkernel without any relation to any shipping stable drm/i915
release, so the backports of the bugfixes are again meaningless and
untested for anything else.

Tbh the easies for us to support is what rhel does for their updates,
which is just copy all of drivers/gpu/ into their old lts kernel and then
fix things up at the seams.

> And if your customers are not using stable kernel releases, what are
> they using for their kernels?

LTS, but with a frankenstein drm/i915. To clarify, all I'm discussing here
is just drm and drm/i915 patches, I think for core code the stable process
works reasonably well (afaiui at least).

> It sounds like you don't want to deal with the "automated" patches for
> the i915 drivers, so that's fine, we will blacklist them and ignore
> them and only deal with the patches you explicitly ask to be backported.
> As it seems like those are hard enough for you all to deal with, given
> the recent regression :)

Yeah that would at least not make it worse.

On the entire problem (that we share with amd folks, see Alex' reply) of
how to ship gpu kernel driver updates to people who care, but don't want
to track latest upstream releases, I'd love to have a solution. I just
don't see one (except tons of manual backport work).

Fundamentally the problem is that the product freeze cycle for core kernel
code (measured in years often) is just plain unsuitable for gfx drivers
(where in userspace we often end up shipping well-tested points from
master because the quarterly releases are too slow).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: 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)

[Greg KH]

On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote:
> Of course our CI is open, so if someone is supremely bored and wants to
> backport more stuff for drm/i915, they could do that. But atm it doesn't
> happen, and then having to deal with the fallout is not really great (like
> I said, we don't really have anyone dedicated, and I much prefer we
> fix/improve upstream).

Any reason you can't add the stable -rc tree to your CI system?

> For the actual products we're shipping we have dedicated teams doing the
> backports. The upstream stable releases essentially have no value for us
> from a customer support pov (for drivers, I guess core stuff is an
> entirely different matter), there's not a single serious customer or
> bigger user using that. It only costs, by spamming us with mails and bug
> reports for stuff we didn't even nominate :-)

Any reason why you aren't sending those backported patches to the stable
trees so that users of them can benefit from the work you are already
doing for a limited number of "customers"?

And if your customers are not using stable kernel releases, what are
they using for their kernels?

It sounds like you don't want to deal with the "automated" patches for
the i915 drivers, so that's fine, we will blacklist them and ignore
them and only deal with the patches you explicitly ask to be backported.
As it seems like those are hard enough for you all to deal with, given
the recent regression :)

thanks,

greg k-h

Re: 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)

[Greg KH]

On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote:
> Of course our CI is open, so if someone is supremely bored and wants to
> backport more stuff for drm/i915, they could do that. But atm it doesn't
> happen, and then having to deal with the fallout is not really great (like
> I said, we don't really have anyone dedicated, and I much prefer we
> fix/improve upstream).

Any reason you can't add the stable -rc tree to your CI system?

> For the actual products we're shipping we have dedicated teams doing the
> backports. The upstream stable releases essentially have no value for us
> from a customer support pov (for drivers, I guess core stuff is an
> entirely different matter), there's not a single serious customer or
> bigger user using that. It only costs, by spamming us with mails and bug
> reports for stuff we didn't even nominate :-)

Any reason why you aren't sending those backported patches to the stable
trees so that users of them can benefit from the work you are already
doing for a limited number of "customers"?

And if your customers are not using stable kernel releases, what are
they using for their kernels?

It sounds like you don't want to deal with the "automated" patches for
the i915 drivers, so that's fine, we will blacklist them and ignore
them and only deal with the patches you explicitly ask to be backported.
As it seems like those are hard enough for you all to deal with, given
the recent regression :)

thanks,

greg k-h

Re: 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)

[Dave Airlie]

On 20 November 2017 at 23:13, Daniel Vetter  wrote:
> On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote:
>> On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote:
>> > Hi all,
>> >
>> > Since I'm going slightly off-topic, I've tweaked the subject line and
>> > trimmed some of the conversation.
>> > I believe everyone in the CC list might be interested in the
>> > following, yet feel free to adjust.
>> >
>> > Above all, I'd kindly ask everyone to skim through and draw their 
>> > conclusions.
>> > If the ideas put forward have some value - great, if not - let my email 
>> > rot.
>> >
>> > On 17 November 2017 at 13:57, Greg KH  wrote:
>> >
>> > >>
>> > >> I still have no idea how this autoselect picks up patches that do *not*
>> > >> have cc: stable nor Fixes: from us. What information do you have that we
>> > >> don't for making that call?
>> > >
>> > > I'll let Sasha describe how he's doing this, but in the end, does it
>> > > really matter _how_ it is done, vs. the fact that it seems to at least
>> > > one human reviewer that this is a patch that _should_ be included based
>> > > on the changelog text and the code patch?
>> > >
>> > > By having this review process that Sasha is providing, he's saying
>> > > "Here's a patch that I think might be good for stable, do you object?"
>> > >
>> > > If you do, great, no harm done, all is fine, the patch is dropped.  If
>> > > you don't object, just ignore the email and the patch gets merged.
>> > >
>> > > If you don't want any of this to happen for your subsystem at all, then
>> > > also fine, just let us know and we will ignore it entirely.
>> > >
>> > Let me start with saying that I'm handling the releases for Mesa 3D -
>> > the project providing OpenGL, Vulkan and many other userspace graphics
>> > drivers.
>> > I've been doing that for 3 years now, which admittedly is quite a
>> > short time relative to the kernel.
>> >
>> > There is a procedure quite similar to the kernel, with a few
>> > differences - see below for details.
>> > We also autoselect patches, hence my interest in the heuristics
>> > applied for nominating patches ;-)
>> >
>> > That aside, here are some things I've learned from my experience.
>> > Some of those may not be applicable - hope you'll find them useful:
>> >
>> >  - Try to reference developers to existing documentation/procedure.
>> > Was just reminded that even long standing developers can forget detail X 
>> > or Y.
>> >
>> >  - CC developers for the important stuff - aka do not CC on each accepted 
>> > patch.
>> > Accepted patches are merged in pre-release branch and a email with
>> > accepted/deferred/rejected list is sent.
>> > Patches that had conflicts merging, and ones that are rejected have
>> > their author in the CC list.
>> > Rejected patches have brief description + developers are contacted 
>> > beforehand.
>> >
>> >  - Autoselect patches are merged only with the approval from the
>> > respective developers.
>> > IMHO this engages developers into the process, without distracting
>> > them too much.
>>
>> Getting explicit confirmation for autoselected patches sounds like a very
>> good idea to me. We intentionally limit the amount of patches we cc:
>> stable, because we simply don't have the manpower around to support stable
>> fully (i.e. with proper CI and everything). And less backported patches
>> means fewer regressions, which is more important than fixing someone
>> else's bug.
>>
>> Of course our CI is open, so if someone is supremely bored and wants to
>> backport more stuff for drm/i915, they could do that. But atm it doesn't
>> happen, and then having to deal with the fallout is not really great (like
>> I said, we don't really have anyone dedicated, and I much prefer we
>> fix/improve upstream).
>>
>> For the actual products we're shipping we have dedicated teams doing the
>> backports. The upstream stable releases essentially have no value for us
>> from a customer support pov (for drivers, I guess core stuff is an
>> entirely different matter), there's not a single serious customer or
>> bigger user using that. It only costs, by spamming us with mails and bug
>> reports for stuff we didn't even nominate :-)
>>
>> Just my 2 cents here, but I think this perpespective matches with other
>> big drm drivers like amdgpu (I just discussed this exact topic of how
>> upstream stable is useless with Alex).
>
> Just to clarify, this includes non-(directly-)paying customers like community
> distros: Either they track the quarterly releases (of both the kernel and
> userspace) because they care about the latest gpu driver work. Or they
> want LTS and stability uber alles, and in that case being aggressive with
> backporting and increases the regression risk doesn't help either.

For Fedora, I think using stable would be appreciated. So you don't cover
community distros if you don't do some stable work.

It follows upstream kernel releases, and we still 

Re: 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)

[Dave Airlie]

On 20 November 2017 at 23:13, Daniel Vetter  wrote:
> On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote:
>> On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote:
>> > Hi all,
>> >
>> > Since I'm going slightly off-topic, I've tweaked the subject line and
>> > trimmed some of the conversation.
>> > I believe everyone in the CC list might be interested in the
>> > following, yet feel free to adjust.
>> >
>> > Above all, I'd kindly ask everyone to skim through and draw their 
>> > conclusions.
>> > If the ideas put forward have some value - great, if not - let my email 
>> > rot.
>> >
>> > On 17 November 2017 at 13:57, Greg KH  wrote:
>> >
>> > >>
>> > >> I still have no idea how this autoselect picks up patches that do *not*
>> > >> have cc: stable nor Fixes: from us. What information do you have that we
>> > >> don't for making that call?
>> > >
>> > > I'll let Sasha describe how he's doing this, but in the end, does it
>> > > really matter _how_ it is done, vs. the fact that it seems to at least
>> > > one human reviewer that this is a patch that _should_ be included based
>> > > on the changelog text and the code patch?
>> > >
>> > > By having this review process that Sasha is providing, he's saying
>> > > "Here's a patch that I think might be good for stable, do you object?"
>> > >
>> > > If you do, great, no harm done, all is fine, the patch is dropped.  If
>> > > you don't object, just ignore the email and the patch gets merged.
>> > >
>> > > If you don't want any of this to happen for your subsystem at all, then
>> > > also fine, just let us know and we will ignore it entirely.
>> > >
>> > Let me start with saying that I'm handling the releases for Mesa 3D -
>> > the project providing OpenGL, Vulkan and many other userspace graphics
>> > drivers.
>> > I've been doing that for 3 years now, which admittedly is quite a
>> > short time relative to the kernel.
>> >
>> > There is a procedure quite similar to the kernel, with a few
>> > differences - see below for details.
>> > We also autoselect patches, hence my interest in the heuristics
>> > applied for nominating patches ;-)
>> >
>> > That aside, here are some things I've learned from my experience.
>> > Some of those may not be applicable - hope you'll find them useful:
>> >
>> >  - Try to reference developers to existing documentation/procedure.
>> > Was just reminded that even long standing developers can forget detail X 
>> > or Y.
>> >
>> >  - CC developers for the important stuff - aka do not CC on each accepted 
>> > patch.
>> > Accepted patches are merged in pre-release branch and a email with
>> > accepted/deferred/rejected list is sent.
>> > Patches that had conflicts merging, and ones that are rejected have
>> > their author in the CC list.
>> > Rejected patches have brief description + developers are contacted 
>> > beforehand.
>> >
>> >  - Autoselect patches are merged only with the approval from the
>> > respective developers.
>> > IMHO this engages developers into the process, without distracting
>> > them too much.
>>
>> Getting explicit confirmation for autoselected patches sounds like a very
>> good idea to me. We intentionally limit the amount of patches we cc:
>> stable, because we simply don't have the manpower around to support stable
>> fully (i.e. with proper CI and everything). And less backported patches
>> means fewer regressions, which is more important than fixing someone
>> else's bug.
>>
>> Of course our CI is open, so if someone is supremely bored and wants to
>> backport more stuff for drm/i915, they could do that. But atm it doesn't
>> happen, and then having to deal with the fallout is not really great (like
>> I said, we don't really have anyone dedicated, and I much prefer we
>> fix/improve upstream).
>>
>> For the actual products we're shipping we have dedicated teams doing the
>> backports. The upstream stable releases essentially have no value for us
>> from a customer support pov (for drivers, I guess core stuff is an
>> entirely different matter), there's not a single serious customer or
>> bigger user using that. It only costs, by spamming us with mails and bug
>> reports for stuff we didn't even nominate :-)
>>
>> Just my 2 cents here, but I think this perpespective matches with other
>> big drm drivers like amdgpu (I just discussed this exact topic of how
>> upstream stable is useless with Alex).
>
> Just to clarify, this includes non-(directly-)paying customers like community
> distros: Either they track the quarterly releases (of both the kernel and
> userspace) because they care about the latest gpu driver work. Or they
> want LTS and stability uber alles, and in that case being aggressive with
> backporting and increases the regression risk doesn't help either.

For Fedora, I think using stable would be appreciated. So you don't cover
community distros if you don't do some stable work.

It follows upstream kernel releases, and we still rarely manage to get an i915
that worked on 4.x 

Re: 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)

[Alex Deucher]

On Mon, Nov 20, 2017 at 8:13 AM, Daniel Vetter  wrote:
> On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote:
>> On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote:
>> > Hi all,
>> >
>> > Since I'm going slightly off-topic, I've tweaked the subject line and
>> > trimmed some of the conversation.
>> > I believe everyone in the CC list might be interested in the
>> > following, yet feel free to adjust.
>> >
>> > Above all, I'd kindly ask everyone to skim through and draw their 
>> > conclusions.
>> > If the ideas put forward have some value - great, if not - let my email 
>> > rot.
>> >
>> > On 17 November 2017 at 13:57, Greg KH  wrote:
>> >
>> > >>
>> > >> I still have no idea how this autoselect picks up patches that do *not*
>> > >> have cc: stable nor Fixes: from us. What information do you have that we
>> > >> don't for making that call?
>> > >
>> > > I'll let Sasha describe how he's doing this, but in the end, does it
>> > > really matter _how_ it is done, vs. the fact that it seems to at least
>> > > one human reviewer that this is a patch that _should_ be included based
>> > > on the changelog text and the code patch?
>> > >
>> > > By having this review process that Sasha is providing, he's saying
>> > > "Here's a patch that I think might be good for stable, do you object?"
>> > >
>> > > If you do, great, no harm done, all is fine, the patch is dropped.  If
>> > > you don't object, just ignore the email and the patch gets merged.
>> > >
>> > > If you don't want any of this to happen for your subsystem at all, then
>> > > also fine, just let us know and we will ignore it entirely.
>> > >
>> > Let me start with saying that I'm handling the releases for Mesa 3D -
>> > the project providing OpenGL, Vulkan and many other userspace graphics
>> > drivers.
>> > I've been doing that for 3 years now, which admittedly is quite a
>> > short time relative to the kernel.
>> >
>> > There is a procedure quite similar to the kernel, with a few
>> > differences - see below for details.
>> > We also autoselect patches, hence my interest in the heuristics
>> > applied for nominating patches ;-)
>> >
>> > That aside, here are some things I've learned from my experience.
>> > Some of those may not be applicable - hope you'll find them useful:
>> >
>> >  - Try to reference developers to existing documentation/procedure.
>> > Was just reminded that even long standing developers can forget detail X 
>> > or Y.
>> >
>> >  - CC developers for the important stuff - aka do not CC on each accepted 
>> > patch.
>> > Accepted patches are merged in pre-release branch and a email with
>> > accepted/deferred/rejected list is sent.
>> > Patches that had conflicts merging, and ones that are rejected have
>> > their author in the CC list.
>> > Rejected patches have brief description + developers are contacted 
>> > beforehand.
>> >
>> >  - Autoselect patches are merged only with the approval from the
>> > respective developers.
>> > IMHO this engages developers into the process, without distracting
>> > them too much.
>>
>> Getting explicit confirmation for autoselected patches sounds like a very
>> good idea to me. We intentionally limit the amount of patches we cc:
>> stable, because we simply don't have the manpower around to support stable
>> fully (i.e. with proper CI and everything). And less backported patches
>> means fewer regressions, which is more important than fixing someone
>> else's bug.
>>
>> Of course our CI is open, so if someone is supremely bored and wants to
>> backport more stuff for drm/i915, they could do that. But atm it doesn't
>> happen, and then having to deal with the fallout is not really great (like
>> I said, we don't really have anyone dedicated, and I much prefer we
>> fix/improve upstream).
>>
>> For the actual products we're shipping we have dedicated teams doing the
>> backports. The upstream stable releases essentially have no value for us
>> from a customer support pov (for drivers, I guess core stuff is an
>> entirely different matter), there's not a single serious customer or
>> bigger user using that. It only costs, by spamming us with mails and bug
>> reports for stuff we didn't even nominate :-)
>>
>> Just my 2 cents here, but I think this perpespective matches with other
>> big drm drivers like amdgpu (I just discussed this exact topic of how
>> upstream stable is useless with Alex).
>
> Just to clarify, this includes non-(directly-)paying customers like community
> distros: Either they track the quarterly releases (of both the kernel and
> userspace) because they care about the latest gpu driver work. Or they
> want LTS and stability uber alles, and in that case being aggressive with
> backporting and increases the regression risk doesn't help either.

We are in pretty much the same situation for amdgpu.  We have very
few, if any, direct customers using upstream.  We have also have
dedicated teams for things like OEM preloads 

Re: 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)

[Alex Deucher]

On Mon, Nov 20, 2017 at 8:13 AM, Daniel Vetter  wrote:
> On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote:
>> On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote:
>> > Hi all,
>> >
>> > Since I'm going slightly off-topic, I've tweaked the subject line and
>> > trimmed some of the conversation.
>> > I believe everyone in the CC list might be interested in the
>> > following, yet feel free to adjust.
>> >
>> > Above all, I'd kindly ask everyone to skim through and draw their 
>> > conclusions.
>> > If the ideas put forward have some value - great, if not - let my email 
>> > rot.
>> >
>> > On 17 November 2017 at 13:57, Greg KH  wrote:
>> >
>> > >>
>> > >> I still have no idea how this autoselect picks up patches that do *not*
>> > >> have cc: stable nor Fixes: from us. What information do you have that we
>> > >> don't for making that call?
>> > >
>> > > I'll let Sasha describe how he's doing this, but in the end, does it
>> > > really matter _how_ it is done, vs. the fact that it seems to at least
>> > > one human reviewer that this is a patch that _should_ be included based
>> > > on the changelog text and the code patch?
>> > >
>> > > By having this review process that Sasha is providing, he's saying
>> > > "Here's a patch that I think might be good for stable, do you object?"
>> > >
>> > > If you do, great, no harm done, all is fine, the patch is dropped.  If
>> > > you don't object, just ignore the email and the patch gets merged.
>> > >
>> > > If you don't want any of this to happen for your subsystem at all, then
>> > > also fine, just let us know and we will ignore it entirely.
>> > >
>> > Let me start with saying that I'm handling the releases for Mesa 3D -
>> > the project providing OpenGL, Vulkan and many other userspace graphics
>> > drivers.
>> > I've been doing that for 3 years now, which admittedly is quite a
>> > short time relative to the kernel.
>> >
>> > There is a procedure quite similar to the kernel, with a few
>> > differences - see below for details.
>> > We also autoselect patches, hence my interest in the heuristics
>> > applied for nominating patches ;-)
>> >
>> > That aside, here are some things I've learned from my experience.
>> > Some of those may not be applicable - hope you'll find them useful:
>> >
>> >  - Try to reference developers to existing documentation/procedure.
>> > Was just reminded that even long standing developers can forget detail X 
>> > or Y.
>> >
>> >  - CC developers for the important stuff - aka do not CC on each accepted 
>> > patch.
>> > Accepted patches are merged in pre-release branch and a email with
>> > accepted/deferred/rejected list is sent.
>> > Patches that had conflicts merging, and ones that are rejected have
>> > their author in the CC list.
>> > Rejected patches have brief description + developers are contacted 
>> > beforehand.
>> >
>> >  - Autoselect patches are merged only with the approval from the
>> > respective developers.
>> > IMHO this engages developers into the process, without distracting
>> > them too much.
>>
>> Getting explicit confirmation for autoselected patches sounds like a very
>> good idea to me. We intentionally limit the amount of patches we cc:
>> stable, because we simply don't have the manpower around to support stable
>> fully (i.e. with proper CI and everything). And less backported patches
>> means fewer regressions, which is more important than fixing someone
>> else's bug.
>>
>> Of course our CI is open, so if someone is supremely bored and wants to
>> backport more stuff for drm/i915, they could do that. But atm it doesn't
>> happen, and then having to deal with the fallout is not really great (like
>> I said, we don't really have anyone dedicated, and I much prefer we
>> fix/improve upstream).
>>
>> For the actual products we're shipping we have dedicated teams doing the
>> backports. The upstream stable releases essentially have no value for us
>> from a customer support pov (for drivers, I guess core stuff is an
>> entirely different matter), there's not a single serious customer or
>> bigger user using that. It only costs, by spamming us with mails and bug
>> reports for stuff we didn't even nominate :-)
>>
>> Just my 2 cents here, but I think this perpespective matches with other
>> big drm drivers like amdgpu (I just discussed this exact topic of how
>> upstream stable is useless with Alex).
>
> Just to clarify, this includes non-(directly-)paying customers like community
> distros: Either they track the quarterly releases (of both the kernel and
> userspace) because they care about the latest gpu driver work. Or they
> want LTS and stability uber alles, and in that case being aggressive with
> backporting and increases the regression risk doesn't help either.

We are in pretty much the same situation for amdgpu.  We have very
few, if any, direct customers using upstream.  We have also have
dedicated teams for things like OEM preloads and distro enablement and
in many cases we 

Re: 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)

[Daniel Vetter]

On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote:
> On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote:
> > Hi all,
> > 
> > Since I'm going slightly off-topic, I've tweaked the subject line and
> > trimmed some of the conversation.
> > I believe everyone in the CC list might be interested in the
> > following, yet feel free to adjust.
> > 
> > Above all, I'd kindly ask everyone to skim through and draw their 
> > conclusions.
> > If the ideas put forward have some value - great, if not - let my email rot.
> > 
> > On 17 November 2017 at 13:57, Greg KH  wrote:
> > 
> > >>
> > >> I still have no idea how this autoselect picks up patches that do *not*
> > >> have cc: stable nor Fixes: from us. What information do you have that we
> > >> don't for making that call?
> > >
> > > I'll let Sasha describe how he's doing this, but in the end, does it
> > > really matter _how_ it is done, vs. the fact that it seems to at least
> > > one human reviewer that this is a patch that _should_ be included based
> > > on the changelog text and the code patch?
> > >
> > > By having this review process that Sasha is providing, he's saying
> > > "Here's a patch that I think might be good for stable, do you object?"
> > >
> > > If you do, great, no harm done, all is fine, the patch is dropped.  If
> > > you don't object, just ignore the email and the patch gets merged.
> > >
> > > If you don't want any of this to happen for your subsystem at all, then
> > > also fine, just let us know and we will ignore it entirely.
> > >
> > Let me start with saying that I'm handling the releases for Mesa 3D -
> > the project providing OpenGL, Vulkan and many other userspace graphics
> > drivers.
> > I've been doing that for 3 years now, which admittedly is quite a
> > short time relative to the kernel.
> > 
> > There is a procedure quite similar to the kernel, with a few
> > differences - see below for details.
> > We also autoselect patches, hence my interest in the heuristics
> > applied for nominating patches ;-)
> > 
> > That aside, here are some things I've learned from my experience.
> > Some of those may not be applicable - hope you'll find them useful:
> > 
> >  - Try to reference developers to existing documentation/procedure.
> > Was just reminded that even long standing developers can forget detail X or 
> > Y.
> > 
> >  - CC developers for the important stuff - aka do not CC on each accepted 
> > patch.
> > Accepted patches are merged in pre-release branch and a email with
> > accepted/deferred/rejected list is sent.
> > Patches that had conflicts merging, and ones that are rejected have
> > their author in the CC list.
> > Rejected patches have brief description + developers are contacted 
> > beforehand.
> > 
> >  - Autoselect patches are merged only with the approval from the
> > respective developers.
> > IMHO this engages developers into the process, without distracting
> > them too much.
> 
> Getting explicit confirmation for autoselected patches sounds like a very
> good idea to me. We intentionally limit the amount of patches we cc:
> stable, because we simply don't have the manpower around to support stable
> fully (i.e. with proper CI and everything). And less backported patches
> means fewer regressions, which is more important than fixing someone
> else's bug.
> 
> Of course our CI is open, so if someone is supremely bored and wants to
> backport more stuff for drm/i915, they could do that. But atm it doesn't
> happen, and then having to deal with the fallout is not really great (like
> I said, we don't really have anyone dedicated, and I much prefer we
> fix/improve upstream).
> 
> For the actual products we're shipping we have dedicated teams doing the
> backports. The upstream stable releases essentially have no value for us
> from a customer support pov (for drivers, I guess core stuff is an
> entirely different matter), there's not a single serious customer or
> bigger user using that. It only costs, by spamming us with mails and bug
> reports for stuff we didn't even nominate :-)
> 
> Just my 2 cents here, but I think this perpespective matches with other
> big drm drivers like amdgpu (I just discussed this exact topic of how
> upstream stable is useless with Alex).

Just to clarify, this includes non-(directly-)paying customers like community
distros: Either they track the quarterly releases (of both the kernel and
userspace) because they care about the latest gpu driver work. Or they
want LTS and stability uber alles, and in that case being aggressive with
backporting and increases the regression risk doesn't help either.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: 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)

[Daniel Vetter]

On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote:
> On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote:
> > Hi all,
> > 
> > Since I'm going slightly off-topic, I've tweaked the subject line and
> > trimmed some of the conversation.
> > I believe everyone in the CC list might be interested in the
> > following, yet feel free to adjust.
> > 
> > Above all, I'd kindly ask everyone to skim through and draw their 
> > conclusions.
> > If the ideas put forward have some value - great, if not - let my email rot.
> > 
> > On 17 November 2017 at 13:57, Greg KH  wrote:
> > 
> > >>
> > >> I still have no idea how this autoselect picks up patches that do *not*
> > >> have cc: stable nor Fixes: from us. What information do you have that we
> > >> don't for making that call?
> > >
> > > I'll let Sasha describe how he's doing this, but in the end, does it
> > > really matter _how_ it is done, vs. the fact that it seems to at least
> > > one human reviewer that this is a patch that _should_ be included based
> > > on the changelog text and the code patch?
> > >
> > > By having this review process that Sasha is providing, he's saying
> > > "Here's a patch that I think might be good for stable, do you object?"
> > >
> > > If you do, great, no harm done, all is fine, the patch is dropped.  If
> > > you don't object, just ignore the email and the patch gets merged.
> > >
> > > If you don't want any of this to happen for your subsystem at all, then
> > > also fine, just let us know and we will ignore it entirely.
> > >
> > Let me start with saying that I'm handling the releases for Mesa 3D -
> > the project providing OpenGL, Vulkan and many other userspace graphics
> > drivers.
> > I've been doing that for 3 years now, which admittedly is quite a
> > short time relative to the kernel.
> > 
> > There is a procedure quite similar to the kernel, with a few
> > differences - see below for details.
> > We also autoselect patches, hence my interest in the heuristics
> > applied for nominating patches ;-)
> > 
> > That aside, here are some things I've learned from my experience.
> > Some of those may not be applicable - hope you'll find them useful:
> > 
> >  - Try to reference developers to existing documentation/procedure.
> > Was just reminded that even long standing developers can forget detail X or 
> > Y.
> > 
> >  - CC developers for the important stuff - aka do not CC on each accepted 
> > patch.
> > Accepted patches are merged in pre-release branch and a email with
> > accepted/deferred/rejected list is sent.
> > Patches that had conflicts merging, and ones that are rejected have
> > their author in the CC list.
> > Rejected patches have brief description + developers are contacted 
> > beforehand.
> > 
> >  - Autoselect patches are merged only with the approval from the
> > respective developers.
> > IMHO this engages developers into the process, without distracting
> > them too much.
> 
> Getting explicit confirmation for autoselected patches sounds like a very
> good idea to me. We intentionally limit the amount of patches we cc:
> stable, because we simply don't have the manpower around to support stable
> fully (i.e. with proper CI and everything). And less backported patches
> means fewer regressions, which is more important than fixing someone
> else's bug.
> 
> Of course our CI is open, so if someone is supremely bored and wants to
> backport more stuff for drm/i915, they could do that. But atm it doesn't
> happen, and then having to deal with the fallout is not really great (like
> I said, we don't really have anyone dedicated, and I much prefer we
> fix/improve upstream).
> 
> For the actual products we're shipping we have dedicated teams doing the
> backports. The upstream stable releases essentially have no value for us
> from a customer support pov (for drivers, I guess core stuff is an
> entirely different matter), there's not a single serious customer or
> bigger user using that. It only costs, by spamming us with mails and bug
> reports for stuff we didn't even nominate :-)
> 
> Just my 2 cents here, but I think this perpespective matches with other
> big drm drivers like amdgpu (I just discussed this exact topic of how
> upstream stable is useless with Alex).

Just to clarify, this includes non-(directly-)paying customers like community
distros: Either they track the quarterly releases (of both the kernel and
userspace) because they care about the latest gpu driver work. Or they
want LTS and stability uber alles, and in that case being aggressive with
backporting and increases the regression risk doesn't help either.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: 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)

[Daniel Vetter]

On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote:
> Hi all,
> 
> Since I'm going slightly off-topic, I've tweaked the subject line and
> trimmed some of the conversation.
> I believe everyone in the CC list might be interested in the
> following, yet feel free to adjust.
> 
> Above all, I'd kindly ask everyone to skim through and draw their conclusions.
> If the ideas put forward have some value - great, if not - let my email rot.
> 
> On 17 November 2017 at 13:57, Greg KH  wrote:
> 
> >>
> >> I still have no idea how this autoselect picks up patches that do *not*
> >> have cc: stable nor Fixes: from us. What information do you have that we
> >> don't for making that call?
> >
> > I'll let Sasha describe how he's doing this, but in the end, does it
> > really matter _how_ it is done, vs. the fact that it seems to at least
> > one human reviewer that this is a patch that _should_ be included based
> > on the changelog text and the code patch?
> >
> > By having this review process that Sasha is providing, he's saying
> > "Here's a patch that I think might be good for stable, do you object?"
> >
> > If you do, great, no harm done, all is fine, the patch is dropped.  If
> > you don't object, just ignore the email and the patch gets merged.
> >
> > If you don't want any of this to happen for your subsystem at all, then
> > also fine, just let us know and we will ignore it entirely.
> >
> Let me start with saying that I'm handling the releases for Mesa 3D -
> the project providing OpenGL, Vulkan and many other userspace graphics
> drivers.
> I've been doing that for 3 years now, which admittedly is quite a
> short time relative to the kernel.
> 
> There is a procedure quite similar to the kernel, with a few
> differences - see below for details.
> We also autoselect patches, hence my interest in the heuristics
> applied for nominating patches ;-)
> 
> That aside, here are some things I've learned from my experience.
> Some of those may not be applicable - hope you'll find them useful:
> 
>  - Try to reference developers to existing documentation/procedure.
> Was just reminded that even long standing developers can forget detail X or Y.
> 
>  - CC developers for the important stuff - aka do not CC on each accepted 
> patch.
> Accepted patches are merged in pre-release branch and a email with
> accepted/deferred/rejected list is sent.
> Patches that had conflicts merging, and ones that are rejected have
> their author in the CC list.
> Rejected patches have brief description + developers are contacted beforehand.
> 
>  - Autoselect patches are merged only with the approval from the
> respective developers.
> IMHO this engages developers into the process, without distracting
> them too much.

Getting explicit confirmation for autoselected patches sounds like a very
good idea to me. We intentionally limit the amount of patches we cc:
stable, because we simply don't have the manpower around to support stable
fully (i.e. with proper CI and everything). And less backported patches
means fewer regressions, which is more important than fixing someone
else's bug.

Of course our CI is open, so if someone is supremely bored and wants to
backport more stuff for drm/i915, they could do that. But atm it doesn't
happen, and then having to deal with the fallout is not really great (like
I said, we don't really have anyone dedicated, and I much prefer we
fix/improve upstream).

For the actual products we're shipping we have dedicated teams doing the
backports. The upstream stable releases essentially have no value for us
from a customer support pov (for drivers, I guess core stuff is an
entirely different matter), there's not a single serious customer or
bigger user using that. It only costs, by spamming us with mails and bug
reports for stuff we didn't even nominate :-)

Just my 2 cents here, but I think this perpespective matches with other
big drm drivers like amdgpu (I just discussed this exact topic of how
upstream stable is useless with Alex).
-Daniel

> 
> It is by no means a perfect system - input and changes are always appreciated.
> 
> 
> That said, here are some suggestions which should make autosel smoother:
> 
>  - 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.
> 
>  - Make the autoselect nominations _more_ distinct than the normal stable 
> ones.
> Maintainers will want to put more cognitive effort into the patches.
> 
> 
> HTH
> Emil
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: 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)

[Daniel Vetter]

On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote:
> Hi all,
> 
> Since I'm going slightly off-topic, I've tweaked the subject line and
> trimmed some of the conversation.
> I believe everyone in the CC list might be interested in the
> following, yet feel free to adjust.
> 
> Above all, I'd kindly ask everyone to skim through and draw their conclusions.
> If the ideas put forward have some value - great, if not - let my email rot.
> 
> On 17 November 2017 at 13:57, Greg KH  wrote:
> 
> >>
> >> I still have no idea how this autoselect picks up patches that do *not*
> >> have cc: stable nor Fixes: from us. What information do you have that we
> >> don't for making that call?
> >
> > I'll let Sasha describe how he's doing this, but in the end, does it
> > really matter _how_ it is done, vs. the fact that it seems to at least
> > one human reviewer that this is a patch that _should_ be included based
> > on the changelog text and the code patch?
> >
> > By having this review process that Sasha is providing, he's saying
> > "Here's a patch that I think might be good for stable, do you object?"
> >
> > If you do, great, no harm done, all is fine, the patch is dropped.  If
> > you don't object, just ignore the email and the patch gets merged.
> >
> > If you don't want any of this to happen for your subsystem at all, then
> > also fine, just let us know and we will ignore it entirely.
> >
> Let me start with saying that I'm handling the releases for Mesa 3D -
> the project providing OpenGL, Vulkan and many other userspace graphics
> drivers.
> I've been doing that for 3 years now, which admittedly is quite a
> short time relative to the kernel.
> 
> There is a procedure quite similar to the kernel, with a few
> differences - see below for details.
> We also autoselect patches, hence my interest in the heuristics
> applied for nominating patches ;-)
> 
> That aside, here are some things I've learned from my experience.
> Some of those may not be applicable - hope you'll find them useful:
> 
>  - Try to reference developers to existing documentation/procedure.
> Was just reminded that even long standing developers can forget detail X or Y.
> 
>  - CC developers for the important stuff - aka do not CC on each accepted 
> patch.
> Accepted patches are merged in pre-release branch and a email with
> accepted/deferred/rejected list is sent.
> Patches that had conflicts merging, and ones that are rejected have
> their author in the CC list.
> Rejected patches have brief description + developers are contacted beforehand.
> 
>  - Autoselect patches are merged only with the approval from the
> respective developers.
> IMHO this engages developers into the process, without distracting
> them too much.

Getting explicit confirmation for autoselected patches sounds like a very
good idea to me. We intentionally limit the amount of patches we cc:
stable, because we simply don't have the manpower around to support stable
fully (i.e. with proper CI and everything). And less backported patches
means fewer regressions, which is more important than fixing someone
else's bug.

Of course our CI is open, so if someone is supremely bored and wants to
backport more stuff for drm/i915, they could do that. But atm it doesn't
happen, and then having to deal with the fallout is not really great (like
I said, we don't really have anyone dedicated, and I much prefer we
fix/improve upstream).

For the actual products we're shipping we have dedicated teams doing the
backports. The upstream stable releases essentially have no value for us
from a customer support pov (for drivers, I guess core stuff is an
entirely different matter), there's not a single serious customer or
bigger user using that. It only costs, by spamming us with mails and bug
reports for stuff we didn't even nominate :-)

Just my 2 cents here, but I think this perpespective matches with other
big drm drivers like amdgpu (I just discussed this exact topic of how
upstream stable is useless with Alex).
-Daniel

> 
> It is by no means a perfect system - input and changes are always appreciated.
> 
> 
> That said, here are some suggestions which should make autosel smoother:
> 
>  - 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.
> 
>  - Make the autoselect nominations _more_ distinct than the normal stable 
> ones.
> Maintainers will want to put more cognitive effort into the patches.
> 
> 
> HTH
> Emil
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

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)

[Emil Velikov]

Hi all,

Since I'm going slightly off-topic, I've tweaked the subject line and
trimmed some of the conversation.
I believe everyone in the CC list might be interested in the
following, yet feel free to adjust.

Above all, I'd kindly ask everyone to skim through and draw their conclusions.
If the ideas put forward have some value - great, if not - let my email rot.

On 17 November 2017 at 13:57, Greg KH  wrote:

>>
>> I still have no idea how this autoselect picks up patches that do *not*
>> have cc: stable nor Fixes: from us. What information do you have that we
>> don't for making that call?
>
> I'll let Sasha describe how he's doing this, but in the end, does it
> really matter _how_ it is done, vs. the fact that it seems to at least
> one human reviewer that this is a patch that _should_ be included based
> on the changelog text and the code patch?
>
> By having this review process that Sasha is providing, he's saying
> "Here's a patch that I think might be good for stable, do you object?"
>
> If you do, great, no harm done, all is fine, the patch is dropped.  If
> you don't object, just ignore the email and the patch gets merged.
>
> If you don't want any of this to happen for your subsystem at all, then
> also fine, just let us know and we will ignore it entirely.
>
Let me start with saying that I'm handling the releases for Mesa 3D -
the project providing OpenGL, Vulkan and many other userspace graphics
drivers.
I've been doing that for 3 years now, which admittedly is quite a
short time relative to the kernel.

There is a procedure quite similar to the kernel, with a few
differences - see below for details.
We also autoselect patches, hence my interest in the heuristics
applied for nominating patches ;-)

That aside, here are some things I've learned from my experience.
Some of those may not be applicable - hope you'll find them useful:

 - Try to reference developers to existing documentation/procedure.
Was just reminded that even long standing developers can forget detail X or Y.

 - CC developers for the important stuff - aka do not CC on each accepted patch.
Accepted patches are merged in pre-release branch and a email with
accepted/deferred/rejected list is sent.
Patches that had conflicts merging, and ones that are rejected have
their author in the CC list.
Rejected patches have brief description + developers are contacted beforehand.

 - Autoselect patches are merged only with the approval from the
respective developers.
IMHO this engages developers into the process, without distracting
them too much.

It is by no means a perfect system - input and changes are always appreciated.


That said, here are some suggestions which should make autosel smoother:

 - 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.

 - Make the autoselect nominations _more_ distinct than the normal stable ones.
Maintainers will want to put more cognitive effort into the patches.


HTH
Emil

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)

[Emil Velikov]

Hi all,

Since I'm going slightly off-topic, I've tweaked the subject line and
trimmed some of the conversation.
I believe everyone in the CC list might be interested in the
following, yet feel free to adjust.

Above all, I'd kindly ask everyone to skim through and draw their conclusions.
If the ideas put forward have some value - great, if not - let my email rot.

On 17 November 2017 at 13:57, Greg KH  wrote:

>>
>> I still have no idea how this autoselect picks up patches that do *not*
>> have cc: stable nor Fixes: from us. What information do you have that we
>> don't for making that call?
>
> I'll let Sasha describe how he's doing this, but in the end, does it
> really matter _how_ it is done, vs. the fact that it seems to at least
> one human reviewer that this is a patch that _should_ be included based
> on the changelog text and the code patch?
>
> By having this review process that Sasha is providing, he's saying
> "Here's a patch that I think might be good for stable, do you object?"
>
> If you do, great, no harm done, all is fine, the patch is dropped.  If
> you don't object, just ignore the email and the patch gets merged.
>
> If you don't want any of this to happen for your subsystem at all, then
> also fine, just let us know and we will ignore it entirely.
>
Let me start with saying that I'm handling the releases for Mesa 3D -
the project providing OpenGL, Vulkan and many other userspace graphics
drivers.
I've been doing that for 3 years now, which admittedly is quite a
short time relative to the kernel.

There is a procedure quite similar to the kernel, with a few
differences - see below for details.
We also autoselect patches, hence my interest in the heuristics
applied for nominating patches ;-)

That aside, here are some things I've learned from my experience.
Some of those may not be applicable - hope you'll find them useful:

 - Try to reference developers to existing documentation/procedure.
Was just reminded that even long standing developers can forget detail X or Y.

 - CC developers for the important stuff - aka do not CC on each accepted patch.
Accepted patches are merged in pre-release branch and a email with
accepted/deferred/rejected list is sent.
Patches that had conflicts merging, and ones that are rejected have
their author in the CC list.
Rejected patches have brief description + developers are contacted beforehand.

 - Autoselect patches are merged only with the approval from the
respective developers.
IMHO this engages developers into the process, without distracting
them too much.

It is by no means a perfect system - input and changes are always appreciated.


That said, here are some suggestions which should make autosel smoother:

 - 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.

 - Make the autoselect nominations _more_ distinct than the normal stable ones.
Maintainers will want to put more cognitive effort into the patches.


HTH
Emil