lkml.org 
[lkml]   [2018]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Ksummit-discuss] bug-introducing patches
    On Thu, May 03, 2018 at 06:12:36PM +0000, Sasha Levin wrote:
    > I'm also not trying to argue whether 7% is high or low, only that it's 3
    > times as many bugs per line of code than what we get from the merge
    > window.

    Yes but seen differently that's 14 times less bugs than the ones properly
    fixed by applying the process which produces these 7%. We can discuss
    about ways to improve it, but please consider that it must not reduce
    the number of correct fixes represented by the 93% remaining ones.

    > Isn't the merge window supposed to be the "risky" part?

    "risky" might not be the correct term. Each single line of code comes
    with a risk. I'd say the "most risky" part. As I said, what I agree with
    the fact that early fixes just before a release have more chances of
    affecting users, which in my opinion is the real problem. Education can
    help here.

    > For example, how about extending the release cycle until the amount of
    > fixes for regressions introduced in the current merge window drops under
    > a certain thershold? (so go to -rc20 if we need to).

    Never works. And Linus already explained it : you cannot stop the development
    process. While you're waiting, development continues, and the next merge
    window gets twice the number of commits, which causes more than twice the
    amount of problems. I've also experienced it in haproxy many years ago. I
    made the mistake of saying "I'm finishing this, only 6 months, and I release
    1.5". Result: bugs coming in parallel to development stalling progress
    forever and it took 4.5 years to release it, or 9 times the expected amount
    of time. Now we release approximately on time, missing features go in the
    next release, easily testable fixes are merged, complex ones are postponed
    for the stable releases with a note in the announce saying "don't play with
    this yet, it's broken". We do ship with bugs, we're open about it and we
    address them later. Overall this transparency is much appreciated. And we
    also do regressions by the way.

    Maybe in the end the only thing we're missing is a "known bugs" section in
    release announcements, so that those with pending fixes are encouraged to
    send a line or two to Linus for inclusion there, having more time to work
    on their fixes.

    Willy

    \
     
     \ /
      Last update: 2018-05-03 21:04    [W:4.491 / U:0.484 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site