[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240611113855.b63a6015b26a0dad49d9f2a7@linux-foundation.org>
Date: Tue, 11 Jun 2024 11:38:55 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Dan Carpenter <dan.carpenter@...aro.org>
Cc: Thorsten Leemhuis <linux@...mhuis.info>, Andy Whitcroft
<apw@...onical.com>, Joe Perches <joe@...ches.com>, Dwaipayan Ray
<dwaipayanray1@...il.com>, Lukas Bulwahn <lukas.bulwahn@...il.com>,
linux-kernel@...r.kernel.org, Greg Kroah-Hartman
<gregkh@...uxfoundation.org>, Arnd Bergmann <arnd@...db.de>, Kees Cook
<keescook@...omium.org>, Sasha Levin <sashal@...nel.org>, Tom Gall
<tom.gall@...aro.org>, kernel-janitors@...r.kernel.org
Subject: Re: [PATCH v5] checkpatch: check for missing Fixes tags
On Tue, 11 Jun 2024 16:43:29 +0300 Dan Carpenter <dan.carpenter@...aro.org> wrote:
> This check looks for common words that probably indicate a patch
> is a fix. For now the regex is:
>
> (?:(?:BUG: K.|UB)SAN: |Call Trace:|stable\@|syzkaller)/)
>
> Why are stable patches encouraged to have a fixes tag? Some people mark
> their stable patches as "# 5.10" etc. This is useful but a Fixes tag is
> still a good idea.
I'd say that "# 5.10" is lame and it would be good if checkpatch could
detect this and warn "hey, use a proper Fixes:". Because
> It helps people to not cherry-pick buggy patches without also
> cherry-picking the fix.
seems pretty important.
Powered by blists - more mailing lists