Re: [PATCH next] Fix the build failed caused by -Wstringop-overflow

["Gustavo A. R. Silva" <gustavo@embeddedor.com>]

On 11/30/23 11:50, Andy Shevchenko wrote:
> On Thu, Nov 30, 2023 at 07:48:46PM +0200, Andy Shevchenko wrote:
>> On Thu, Nov 30, 2023 at 09:52:42AM -0600, Gustavo A. R. Silva wrote:
>>> On 11/30/23 04:57, Wenyu Huang wrote:
> 
> ...
> 
>>>> Fixes: 89741e7e42f6 ("Makefile: Enable -Wstringop-overflow globally")
>>>
>>> The commit ID is from a patch that's currently in linux-next, which
>>> does not guarantee it's a stable commit. So, it shouldn't be used
>>> for any tag in any changelog text. In fact, it has changed a couple
>>> of times in the last couple of weeks.
>>
>> I disagree on this in general.
>>
>> The case in practice I have. I does something in new cycle that broke the
>> enumeration of some devices. The patch is in the maintainer's tree pending
>> for the next release (v6.8-rc1). There are I see two options:
>> - revert patch completely and redo it properly
>> - add a fix (which is one liner)
>>
>> Now, what you are suggesting is to drop the Fixes tag on the grounds that
>> the culprit and the fix are to be in the same release (as we go let's say
>> with the latter approach). In case that the culprit will be backported
>> (let's say to satisfy dependencies, as per se it's not a fix), it will
>> bring a regression and become unnoticed for some time until first reports
>> will appear. Additional resources would be need for all this.
>>
>> So, I'm fully in favour of using Fixes tag as it makes clear if we have
>> some broken changes in the kernel for which the fix is known and exists.
> 
> On top of that, Fixes tag is not enough to get it to stable. See the rules
> on how to submit a material to stable kernels, it's in the documentation.

We are talking about different things. I'm talking about commit IDs staying
unchanged (stable commit IDs). That's different to stable kernels. :)

--
Gustavo