Patch "drm: Fix color LUT rounding" has been added to the 6.7-stable tree

[Sasha Levin]

On Fri, Feb 02, 2024 at 02:14:40PM -0600, Lucas De Marchi wrote:
>On Fri, Feb 02, 2024 at 02:38:57PM -0500, Sasha Levin wrote:
>>On Fri, Feb 02, 2024 at 11:35:33AM -0600, Lucas De Marchi wrote:
>>>On Fri, Feb 02, 2024 at 06:53:03PM +0200, Ville Syrjälä wrote:
>>>>On Thu, Feb 01, 2024 at 11:17:28AM -0800, Greg KH wrote:
>>>>>On Thu, Feb 01, 2024 at 08:35:24PM +0200, Ville Syrjälä wrote:
>>>>>>On Thu, Feb 01, 2024 at 10:16:48AM -0800, Greg KH wrote:
>>>>>>>On Thu, Feb 01, 2024 at 08:05:19PM +0200, Ville Syrjälä wrote:
>>>>>>>> On Thu, Feb 01, 2024 at 12:03:20PM -0500, Sasha Levin wrote:
>>>>>>>> > This is a note to let you know that I've just added the patch titled
>>>>>>>> >
>>>>>>>> >     drm: Fix color LUT rounding
>>>>>>>> >
>>>>>>>> > to the 6.7-stable tree which can be found at:
>>>>>>>> >     http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
>>>>>>>> >
>>>>>>>> > The filename of the patch is:
>>>>>>>> >      drm-fix-color-lut-rounding.patch
>>>>>>>> > and it can be found in the queue-6.7 subdirectory.
>>>>>>>> >
>>>>>>>> > If you, or anyone else, feels it should not be added to the stable tree,
>>>>>>>> > please let <stable at vger.kernel.org> know about it.
>>>>>>>>
>>>>>>>> I guess I wasn't clear enough in the other mail...
>>>>>>>>
>>>>>>>> NAK for all of backports of this patch.
>>>>>>>
>>>>>>>Ok, but why?  It seems that you are fixing a real issue here, right?  If
>>>>>>>not, the changelog is not clear with that at all...
>>>>>>>
>>>>>>>I'll go drop it now, thanks.
>>>>>>
>>>>>>Because backporting it would require other backports that depend on
>>>>>>the rounding behaviour.
>>>>>>
>>>>>>Can I somehow fully opt out of these automagic backports?
>>>>>>If I want my stuff backported I'll ask for it.
>>>>>
>>>>>You can, just let me know what exact files should be ignored, or you can
>>>>>send a patch against this file:
>>>>>	https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/ignore_list
>>>>
>>>>I think we should add at least i915 and xe there. cc: maintainers
>>>
>>>It does feel a little wild to decide a patch needs to be backported
>>>based on the commit title starting with "Fix", or whatever way was used
>>>here. We always relied on patches being backported based on a) having a
>>>Fixes: trailer and  b) the commit pointed out in that trailer
>>>being present in that stable version. Or the others options shown
>>>in Documentation/process/stable-kernel-rules.rst
>>>
>>>Looking at the commit in question, c6fbb6bca10838485b820e8a26c23996f77ce580
>>>there's no such a trailer. Did I miss something from
>>>Documentation/process/stable-kernel-rules.rst?
>>
>>Where did you see anything about the Fixes: trailer in the document
>>you've pointed to?
>
>End of "Option 1":
>
>   Note, such tagging is unnecessary if the stable team can derive the
>   appropriate versions from Fixes: tags.

Let me quote the entire section containing the sentence you've pasted
above:

> * For patches that may have kernel version prerequisites specify them using
>   the following format in the sign-off area:
>
>   .. code-block:: none
>
>     Cc: <stable at vger.kernel.org> # 3.3.x
>
>   The tag has the meaning of:
>
>   .. code-block:: none
>
>     git cherry-pick <this commit>
>
>   For each "-stable" tree starting with the specified version.
>
>   Note, such tagging is unnecessary if the stable team can derive the
>   appropriate versions from Fixes: tags.

Looking at the above, does the phrase "such tagging" refer to stable@
tags in general, or to tagging of prerequisite patches?

-- 
Thanks,
Sasha