[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.2006041228520.2577@hadrien>
Date: Thu, 4 Jun 2020 12:33:53 +0200 (CEST)
From: Julia Lawall <julia.lawall@...ia.fr>
To: Joe Perches <joe@...ches.com>
cc: Dan Carpenter <dan.carpenter@...cle.com>,
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, 4 Jun 2020, Joe Perches wrote:
> On Thu, 2020-06-04 at 11:52 +0200, Julia Lawall wrote:
> > Should Fixes also be used when the change will make it hard to port other
> > fixes over it?
>
> If it's a logic defect or regression that's being fixed,
> shouldn't the logic defect or regression be fixed as
> reasonably soon as possible?
Sure, but I recall seeing some patches that mentioned that the problem had
existed since the beginning of git. Of course, it should be rare.
>
> The nature of the fix should ideally be optimal for
> backporting, but I believe that should not stop any
> consideration for the standalone fix itself.
I'm not sure to follow this. Sometimes non-bug fixes that block
backporting a bug fix have to be backported as well. So the fixes would
again highlight the range of versions affected by the issue.
julia
> What do you think?
>
>
Powered by blists - more mailing lists