[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0749ac5e3868c6ba50728ced8366bfd86b0b8500.camel@perches.com>
Date: Thu, 04 Jun 2020 09:08:44 -0700
From: Joe Perches <joe@...ches.com>
To: Dan Carpenter <dan.carpenter@...cle.com>,
Julia Lawall <julia.lawall@...ia.fr>
Cc: Linus Walleij <linus.walleij@...aro.org>,
Christophe JAILLET <christophe.jaillet@...adoo.fr>,
Robert Jarzmik <robert.jarzmik@...e.fr>,
Daniel Mack <daniel@...que.org>,
Haojian Zhuang <haojian.zhuang@...il.com>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] pinctrl: pxa: pxa2xx: Remove 'pxa2xx_pinctrl_exit()'
which is unused and broken
On Thu, 2020-06-04 at 15:30 +0300, Dan Carpenter wrote:
> On Thu, Jun 04, 2020 at 01:42:12PM +0200, Julia Lawall wrote:
> > 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. 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.
Compiler silencing changes marked as fixes can introduce other
defects in working code.
Backporting patches to stable trees should be conservatively
rather than liberally applied.
It seems that the actual backport maintainers disagree though.
Powered by blists - more mailing lists