lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5hwqoqv4oo.wl%tiwai@suse.de>
Date:	Tue, 16 Jul 2013 18:40:39 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	David Lang <david@...g.hm>
Cc:	Willy Tarreau <w@....eu>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	ksummit-2013-discuss@...ts.linux-foundation.org,
	torvalds@...ux-foundation.org
Subject: Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

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?)


Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ