[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180503023052.GA12856@1wt.eu>
Date: Thu, 3 May 2018 04:30:52 +0200
From: Willy Tarreau <w@....eu>
To: Guenter Roeck <linux@...ck-us.net>
Cc: "Theodore Y. Ts'o" <tytso@....edu>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Sasha Levin <Alexander.Levin@...rosoft.com>,
Greg KH <gregkh@...uxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"ksummit-discuss@...ts.linuxfoundation.org"
<ksummit-discuss@...ts.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] bug-introducing patches
On Wed, May 02, 2018 at 05:38:32PM -0700, Guenter Roeck wrote:
> > Because if that last is the case, then the prescription is very simple
> > and not controversial --- bug fixes found post -rc4 should be held to
> > the next merge window.
> >
>
> Holding up even fixes for severe bugs for 4-6 weeks ? Seriously, that is
> unrealistic. Holding up the fix for the next SpeckHammer because it was not
> ready before -rc4 ? I don't think so.
That's exactly what I explained earlier in this thread, it will actually
make the resulting kernels even worse as soon as there is less than 100%
regression (which is the case, since some fixes are valid). Postponing
valid fixes because some of them might be wrong is a bad idea. We need
to trust the developer regarding the test coverage and the developer has
to become trusted by openly indicating the type of testing run on the
patch. From there it will become easier to decide whether to revert a
whole patch set after a few failed fixes, or to take a few more fixes
in hopes that ultimately everything will be good.
Willy
Powered by blists - more mailing lists