lkml.org 
[lkml]   [2008]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Slow DOWN, please!!!
    On Wed, 30 Apr 2008 21:36:57 +0200
    "Rafael J. Wysocki" <rjw@sisk.pl> wrote:

    > On Wednesday, 30 of April 2008, David Miller wrote:
    > >
    > > This is starting to get beyond frustrating for me.
    > >
    > > Yesterday, I spent the whole day bisecting boot failures
    > > on my system due to the totally untested linux/bitops.h
    > > optimization, which I fully analyzed and debugged.
    > >
    > > Today, I had hoped that I could get some work done of my
    > > own, but that's not the case.
    > >
    > > Yet another bootup regression got added within the last 24
    > > hours.
    > >
    > > I don't mind fixing the regression or two during the merge
    > > window but THIS IS ABSOLUTELY, FUCKING, REDICULIOUS!
    > >
    > > The tree breaks every day, and it's becomming an extremely
    > > non-fun environment to work in.
    > >
    > > We need to slow down the merging, we need to review things
    > > more, we need people to test their fucking changes!
    >
    > Well, I must say I second that.

    ooh, fun thread.

    One of the main reasons for -mm (probably _the_ main reason) is to weed out
    other-developer-impacting regressions before they hit mainline and, umm,
    affect developers.

    But there are implementation problems:

    a) developers aren't testing -mm enough

    b) -mm releases have become too slow, and (hence) too unstable

    c) people are slamming changes into mainline which have never been seen
    in -mm. Lots of changes.

    So here's how we're going to fix David's problem:

    - Everyone gets their stuff into linux-next.

    - Lots of people _test_ linux-next. Just once a week.

    Those two steps will improve the merge-window chaos a lot. Things will get
    better.




    The remaining open problem is what do we do about the shiny new code which
    is getting slammed into the merge window?

    Well, it's very easy to tell whether code which appears in the merge window
    was present in linux-next.

    Our first way of preventing people from shoving inadequately-cooked code
    into the merge window is suasion (aka flaming their titties off). If that
    proves insufficient and if we still have a sufficiently large problem that
    we need to do something about it then sure, let's reevaluate.

    But one thing at a time. For the 2.6.27 release let us concentrte on two
    things

    - get your stuff into linux-next

    - test linux-next.

    If merge-window stability is still a problem after that then let's revisit?


    \
     
     \ /
      Last update: 2008-04-30 22:03    [W:0.023 / U:32.364 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site