linux-kernel - RE: [Ksummit-2013-discuss] When to push bug fixes to mainline

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: <3908561D78D1C84285E8C5FCA982C28F31C845B1@ORSMSX106.amr.corp.intel.com>
Date:	Tue, 16 Jul 2013 17:58:58 +0000
From:	"Luck, Tony" <tony.luck@...el.com>
To:	Mark Brown <broonie@...nel.org>, Takashi Iwai <tiwai@...e.de>
CC:	David Lang <david@...g.hm>,
	"ksummit-2013-discuss@...ts.linux-foundation.org" 
	<ksummit-2013-discuss@...ts.linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>,
	"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
	Willy Tarreau <w@....eu>
Subject: RE: [Ksummit-2013-discuss] When to push bug fixes to mainline

>> 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?)
>
> Hopefully people tracking the upstream stable trees would be throwing
> any pre-release stuff into their QA processes before it was officially
> released upstream, though I'd not count on it.

Linux testing is (realistically) done by inflicting changes on gradually wider
sets of end users.

We go through these stages (possibly a couple of extra steps where maintainer trees
are nested)
1) Author of a patch tests on their own machine (and perhaps a few others)
2) Patch is posted. A few more people grab and test.
3) Patch is applied to a maintainer tree, which is slurped into linux-next.
    A few hundred brave folks now have this patch in their binary, but most extra testing
    is purely accidental. These users aren't running focused tests on the area touched
    by the patch.
4) Patch is pulled by Linus. Pretty large jump in the number of users running the code
    so we start to get good breadth of testing on different machines with different sets
    of CONFIG options under varying workloads.
5) Linus releases a final 3.x version - another substantial bump in the number of testers
    because there are lots of people who wait for "release" quality kernels.
6) Fedora, Ubuntu etc. use this 3.x kernel as basis for a release. Probably two or three
    orders of magnitude more users (but only a fraction of their problems are reported
    back to LKML).

Thus code does get more and more QA - the longer you wait before taking a patch the
lower the risk that it has some unintended side-effect or outright bug . But of course
you are vulnerable in this whole period to whatever issue the patch was actually
trying to fix. So you have a classic tradeoff.

-Tony
--
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/