On Thu, 2020-06-04 at 20:35 +0300, Dan Carpenter wrote:

On Thu, Jun 04, 2020 at 09:08:44AM -0700, Joe Perches wrote:

quoted

On Thu, 2020-06-04 at 15:30 +0300, Dan Carpenter wrote:

quoted

On Thu, Jun 04, 2020 at 01:42:12PM +0200, Julia Lawall wrote:

quoted

OK, I recall a discussion with Dan where he suggested that some things
that were not actually bug fixes could also merit a Fixes tag.  But it's
probably better if he weighs in directly.

I generally think Fixes should only be used for "real bug" fixes.

The one exception is when I'm reviewing a patch that fixes an "unused
assignment" static checker warning is that I know which commit
introduced the warning.

Sometimes those warnings are introduced by new compiler
versions.

That's why I don't care for -Werror use in Makefiles.

quoted

quoted

I don't have strong feelings if it's in the
Fixes tag or if it's just mentioned in the commit message.

My view is that changes that silence compiler warnings are
not fixing bugs and that these changes should generally not
be backported.

The Fixes tag is useful for backports but that's not whole the point of
it.  It's also for collecting metrics.

Hmm, how are these metrics used?

Also sometimes we fix the bug
before the kernel is released so the Fixes tag means we can automatically
ignore those ones when we look at which patches to backport.

I don't care if the "unused assignment" patches use a Fixes tag or just
mention the commit.  Either way the information is there for when I
review the patch.

Perhaps there could/should be some distinction between
"real bug" fixes and trivialities like "unused assignment"

Maybe something like:
	Updates: <commit> ("commit description")
vs
	Fixes: <commit> ("commit description")



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel