Messages in this thread | | | Date | Tue, 25 Jan 2022 17:53:59 -0800 | From | Andrew Morton <> | Subject | Re: [RESEND][PATCH] checkpatch: make sure fix-up patches have Fixes tag |
| |
On Wed, 19 Jan 2022 09:48:32 +0000 Andy Whitcroft <apw@canonical.com> wrote:
> On Wed, Jan 19, 2022 at 9:42 AM Joe Perches <joe@perches.com> wrote: > > > > On Wed, 2022-01-19 at 16:46 +0900, Sergey Senozhatsky wrote: > > > If a patch contains "commit hash (commit name)", in other words > > > if the patch fixes some particular commit, then require "Fixes:" > > > tag. > > > > I do not like this patch as many commits merely reference a > > previous patch and do not actually fix anything. > > Agree. It would need to be a tighter form of language to be safe to > automatically suggest a Fixes tag. The point of a Fixes tag is to be > a semantically safe indicator of this relationship not relying on the > vagaries of English for that connection. > > You might be ok with something which is a tighter match on like > "fixes <hash> (<name>)" and only suggesting a Fixes.
Also.
stable tree maintainers appear to have the habit of taking anything which has Fixes and cheerfully backporting it. Sometimes undesirably. This patch will encourage people to worsen this problem.
I wish this would simply stop, kernel-wide. Make developers and tree-owners actually *think* about the backport desirability.
If that were the global approach then checkpatch could
a) ask developers if they should have added "Fixes:" (this patch) then
b) if it has "Fixes:", ask developers if they should have added cc:stable.
| |