[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1525357984.3225.12.camel@HansenPartnership.com>
Date: Thu, 03 May 2018 07:33:04 -0700
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Jani Nikula <jani.nikula@...el.com>,
"Theodore Y. Ts'o" <tytso@....edu>,
Sasha Levin <Alexander.Levin@...rosoft.com>
Cc: 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>, "w@....eu" <w@....eu>
Subject: Re: [Ksummit-discuss] bug-introducing patches
On Thu, 2018-05-03 at 14:08 +0300, Jani Nikula wrote:
> On Tue, 01 May 2018, "Theodore Y. Ts'o" <tytso@....edu> wrote:
> > Post -rc3 or -rc4, in my opinion bug fixes should wait until the
> > next
> > merge window before they get merged at all.
>
> What are -rc5 and later for then if not bug fixes? Baffled.
They're definitely for bug fixes, but there's a spectrum: obvious bug
fixes with no side effects are easy to justify. More complex bug fixes
run the risk of having side effects which introduce other bugs, so
could potentially destabilize the -rc process. In SCSI we tend to look
at what the user visible effects of the bug are in the post -rc5 region
and if they're slight or wouldn't be visible to most users, we'll hold
them over. If the fix looks complex and we're not sure we caught the
ramifications, we often add it to the merge window tree with a cc to
stable and a note saying to wait X weeks before actually adding to the
stable tree just to make sure no side effects show up with wider
testing. So, as with most things, it's a judgment call for the
maintainer.
James
Powered by blists - more mailing lists