Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933875Ab3GPT2k (ORCPT ); Tue, 16 Jul 2013 15:28:40 -0400 Received: from cantor2.suse.de ([195.135.220.15]:48473 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933784Ab3GPT2h (ORCPT ); Tue, 16 Jul 2013 15:28:37 -0400 Date: Tue, 16 Jul 2013 21:29:49 +0200 Message-ID: From: Takashi Iwai To: David Lang Cc: Takashi Iwai , Willy Tarreau , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, stable@vger.kernel.org, ksummit-2013-discuss@lists.linux-foundation.org, torvalds@linux-foundation.org Subject: Re: [Ksummit-2013-discuss] When to push bug fixes to mainline In-Reply-To: References: <20130711214830.611455274@linuxfoundation.org> <20130712005023.GB31005@thunk.org> <20130712051451.GC25815@1wt.eu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.2 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2492 Lines: 61 At Tue, 16 Jul 2013 09:42:34 -0700 (PDT), David Lang wrote: > > On Tue, 16 Jul 2013, Takashi Iwai wrote: > > > At Tue, 16 Jul 2013 00:19:16 -0700 (PDT), > > David Lang wrote: > >> > >> On Fri, 12 Jul 2013, Willy Tarreau wrote: > >> > >>> And maybe in the end, having 1/10 patch cause a regression is not *that* > >>> dramatic, and probably less than not fixing the 9 other bugs. In one case > >>> we rely on -stable to merge the 10 fixes, and on the other case we'd rely > >>> on -stable to just revert one of them. > >> > >> Apologies for the late post, I'm catching up on things, but this jumped out at > >> me. > >> > >> We went through a LOT of pain several years ago when people got into the mindset > >> that a patch was acceptable if it fixed more people than it broke. eliminating > >> that mindset did wonders for kernel stability. > >> > >> Regressions are a lot more of a negative than bugfixes are a positive, a 10:1 > >> ratio of fixes to regressions is _not_ good enough. > > > > IMO, one of the reasons is the nature of stable-release: the stable > > tree is released soon after reviews of patches, so no actual > > regression tests can be done before the release. > > > > For finding a regression, patch reviews won't be enough; all patches > > have been already reviewed, thus essentially they must be all > > positive/good fixes. And the compile is OK. So what's the problem? > > > > Maybe some QA period before the release might help, but who would > > care? (Especially under the situation where everybody has own x.y > > stable tree?) > > I am not saying that no regressions will happen (for exactly the reasons that > you are giving). I don't expect that no regression will happen, too. I'm no dreamer:) But I expect we can reduce the regressions, at least. > what I am complaining about is the attitude that a few regressions are Ok, as > long as there are more fixes than there are regressions. Agreed. And this is the difficult point. No one introduced regressions at its will. Mostly they are overlooked mistakes. So, where is the border line and how to distinguish? Can't we backport uncritical fixes even if users want them explicitly? I guess there seem different opinions on these. thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/