On Mon, Apr 29, 2024 at 3:38 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > Well a Fixes: tag that says "6.1" but yet you only want it applied to > 6.6 and newer is quite confusing, don't you think? This implies that > 6.1 still has problems and that no one will fix them. Yes, 6.1 will still have the problem. Originally I thought about not even submitting that one to stable, since it is a minor build issue that should only affect kernel developers. But since it could be easily applied to 6.6 and 6.8, I decided to propose them for those 2. > So in the future, try to be consistent one way or the other which mean a > fixes tag only with no comment, no fixes tag and just a comment, or a > fixes tag that matches the comment. You picked the one other > combination that was sure to confuse people, nice work :) Got it :) In case it helps, my reading of the docs was that Fixes was meant to be there if the commit that introduced the bug was known and thus the # comment could be used there to "filter" where it would land (since otherwise it would land in all). So, in this case, if I understand correctly, you are saying that I should have removed the Fixes tag since the fix does not actually apply to 6.1, even if the issue it talks about originated in 6.1. So Fixes is more "this can be used to fix commit X when backporting", rather than "this commit fixes a bug introduced in commit X", right? Cheers, Miguel
