lkml.org 
[lkml]   [2013]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Ksummit-2013-discuss] When to push bug fixes to mainline
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).

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.

David Lang


\
 
 \ /
  Last update: 2013-07-16 19:43    [W:1.011 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site