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: <20130716183927.GH15902@1wt.eu>
Date:	Tue, 16 Jul 2013 20:39:27 +0200
From:	Willy Tarreau <w@....eu>
To:	Takashi Iwai <tiwai@...e.de>
Cc:	David Lang <david@...g.hm>,
	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

Hi Takashi,

On Tue, Jul 16, 2013 at 06:40:39PM +0200, Takashi Iwai wrote:
> 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?)

Almost nobody *tests* the previews. Except the few regular testers, but
they test in a finite environment so there is very little coverage in
the end. I'm not dismissing their work, because without them we'd have
zero testers. I'd prefer to have more than we currently have. But it's
also almost impossible to test reviews on servers, so a wide category
of fixes is probably never tested anyway during previews (eg: RAID
cards, or fixes for bugs affecting large amounts of memory/disk/cpus).

What makes the success of -stable is that Greg is able to re-release
very quickly when a bug is reported, sometimes even the same day. It's
something I'm totally incapable of, not having enough contiguous spare
time to work regularly enough on releases. That's the real key to
success. As a user, I look at the changes between versions and generally
only upgrade if something seems to be hitting me. That way I need less
updates and skip more regressions. And I'm sure most users do the same.

Regards,
Willy

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