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
