lkml.org 
[lkml]   [2012]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [ 00/78] 3.3.2-stable review
    On Fri, Apr 13, 2012 at 01:58:10AM +0300, Felipe Contreras wrote:
    > On Fri, Apr 13, 2012 at 1:12 AM, David Miller <davem@davemloft.net> wrote:
    > > From: Felipe Contreras <felipe.contreras@gmail.com>
    > > Date: Fri, 13 Apr 2012 01:04:42 +0300
    > >
    > >> Wrong is wrong, before or after the 3.3.1 tag, this patch is not
    > >> 'stable' material, and removing it does not affect upstream at all.
    > >
    > > What you don't understand is that bug fixes will get lost if you only
    > > fix them in -stable, it doesn't matter HOW THEY GOT into -stable.
    >
    > Let's suppose that c1afdaf was never back-ported from v3.4-rc1, how
    > would you have fond out there was an issue with it? There's 10000
    > patches in v3.4-rc2, how do you expect to find issues in them?
    >
    > People found out this issue on v3.4-rc1, so the fix would not have
    > been lost, but lets assume it would, v3.3.1 had the issue, the patch
    > as reverted in v3.3.2, and v3.4 still had the issue. So what? There's
    > already 10000 patches that would never make it to 3.3.x, and many will
    > have issues, which is why there would be v3.4.x.
    >
    > > In fact IT HAS FUCKING HAPPENED that we didn't fix something upstream
    > > that got fixed in -stable a time long ago when we didn't have the
    > > policy we're using now which you're going so unreasonably ape-shit
    > > about.
    >
    > I see how a *fix* on stable could get lost, but this is not a fix.

    Felipe, you don't seem to get it : there are many bugs in each new release.
    Given the number of fixes Greg merges into a longterm branch, I'd say that
    there are around 1500 bugs waiting to be discovered and fixed in a new
    release. Does this mean we need to fix them all at once ? No, because we
    don't know about them yet.

    The process you're criticizing consists in ensuring that once a bug is known,
    it gets fixed in mainline so that it never appears there again. The way the
    bug is discovered doesn't matter, even if it's discovered that a fix caused
    the bug and that it must be reverted. The fact is mainline is buggy and we
    know this because stable is too. So mainline must be fixed first. This
    process works because stable users are pressuring developers to push their
    fixes to Linus in order to get them. What happened with this bug prooved
    the process is working fine.

    Another point is that you don't want stable to merge, revert, merge again,
    revert again etc... This happened a little bit during 2.6.32 because some
    fixes were not really obvious. It's common for some fixes to have to be
    adapted for stable branches, and to have side effects, hence the review
    cycle. We need to limit these random issues as much as possible if we
    don't want users to lose trust in the stable branches. This is extremely
    important. So picking random fixes that have not been qualified by all
    interested parties in stable is inappropriate. Reverting without evaluating
    impacts is one form of picking a random fix.

    What you should have done would have been to reply to Greg saying "wait a
    minute, we still have an issue with patch XX, I'm trying to get it reverted
    in upstream and will send you the commit ID, it would be nice to have it in
    3.3.2". It wastes less time for everyone and achieves the same result.

    Once again, if you think that the stable branch you're using is not stable
    enough for you, pick another one. Greg maintains multiple branches so that
    everyone is satisfied. The risk of bugs over time probably looks like
    (cos(t)+1)/t. Find an older branch with a much smaller risk of regressions
    and be done with it.

    Last point, you should note that you're the only one here who doesn't
    understand the process. That doesn't make you a fool, but it should tell you
    that you probably need to think a bit further before telling people how they
    should work, especially when all other ones agree on the benefits of the
    process, including Arnd explaining that FreeBSD had been facing the exact
    same trouble and now applies the same process. It is not just a small band
    of nerds doing this for fun right here, but seems to be more generalized.

    Regards
    Willy



    \
     
     \ /
      Last update: 2012-04-13 07:37    [W:4.077 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site