lkml.org 
[lkml]   [2018]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: bug-introducing patches
    Date
    On Tue, May 01, 2018 at 10:33:25PM +0200, Willy Tarreau wrote:
    >On Tue, May 01, 2018 at 08:00:21PM +0000, Sasha Levin wrote:
    >> What's worse is that that commit is tagged for stable, which means
    >> that (given Greg's schedule) it may find it's way to -stable users
    >> even before some -next users/bots had a chance to test it out.
    >
    >But it's a difficult trade-off. I think that -next is mostly used by
    >developers and that as such the audience remains limited. On the
    >opposite, -stable is used by many users. So how many days of -next
    >does it take to get the equivalent coverage of one day of -stable,
    >I don't know but it's probably a lot. Also server workloads are
    >almost exclusively on -stable. So a bug affecting only server users
    >will not benefit from -next exposition.
    >
    >In the end it's all about responding to users' expectations to see
    >the bugs fixed. In -stable we regularly see users asking to backport
    >certain fixes. Sometimes they have to wait one or two extra versions
    >before they get their fix, and they are really not happy at all. If
    >the fix is rushed too fast and doesn't work, they won't be happy
    >either. Making them happy means backporting the right fix the quickest
    >possible. Too little test can result in a wrong fix, but too much test
    >results in a slow backport.
    >
    >Again, I really don't find the -stable situation bad nowadays, quite
    >the opposite. I often suggest to people who don't follow too closely
    >to stick to latest LTS minus 1 or 2 releases. This way they don't get
    >the very latest fixes and have a chance that if something breaks very
    >badly, it gets fixed quickly. It works pretty well apparently.
    >
    >I suspect that some of the issues that really need to be improved are
    >the fixes to recently merged code. That's never easy by definition
    >because if the code is young, it's not yet very well known even by
    >its author.
    >
    >What *could* possibly be done (though I'm not fond of this) would be
    >to state a rule that past a certain number of stacked fixes for a
    >recently merged code, an extra review delay will be enforced on the
    >subsystem or on patches coming from the submitter. But I really doubt
    >it would significantly improve the situation.

    I think that this discussion has shifted to -stable issues, which is not
    what I was aiming for.

    I tried to present a statistic from the recent kernel commits showing
    that per changed line of code, an -rc commit has more than 3 times the
    likelyhood to introduce a bug rather than a merge window one.

    Is this something the community sees as an issue, or do we expect a
    significantly higher odds of introducing bugs in -rc commits?

    Feed free to ignore any proposals I've made. If you see this as an
    issue, what could we do to address it?

    Let's leave -stable out of this for now.
    \
     
     \ /
      Last update: 2018-05-01 22:42    [W:5.408 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site