[lkml]   [2008]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Slow DOWN, please!!!
    On Thursday, 1 of May 2008, Willy Tarreau wrote:
    > On Thu, May 01, 2008 at 12:39:01AM +0200, Rafael J. Wysocki wrote:
    > > On Thursday, 1 of May 2008, David Miller wrote:
    > > > From: Ingo Molnar <>
    > > > Date: Thu, 1 May 2008 00:19:36 +0200
    > > >
    > > > > The same goes in the other direction as well - you were just hit by
    > > > > scheduler tree related regressions that were only triggered on your
    > > > > 128-way sparc64, but not on our 64way x86 and smaller boxes.
    > > >
    > > > You keep saying this over and over again, but the powerpc folks hit
    > > > this stuff too.
    > >
    > > Well, I think that some changes need some wider testing anyway.
    > >
    > > They may be correct from the author's point of view and even from the knowledge
    > > and point of view of the maintainer who takes them into his tree. That's
    > > because no one knows everything and it'll always be like this.
    > >
    > > Still, with the current process such "suspicious" changes go in as parts of
    > > large series of commits and need to be "rediscovered" by the affected testers
    > > with the help of bisection. Moreover, many changes of this kind may go in from
    > > many different sources at the same time and that's really problematic.
    > That's very true IMHO and is the thing which has been progressively
    > appearing since we merge large amounts of code at once. In the "good
    > old days", something did not work, the first one to discover it could
    > quickly report it on LKML : "hey, my 128-way sparc64 does not boot
    > anymore, anybody has any clue", and another one immediately found
    > this mail (better signal/noise ratio on LKML at this time) and say
    > "oops, I suspect that change, try to revert it".
    > Now, it's close to impossible. Maintainers frequently ask for bisection,
    > in part because nobody knows what code is merged, and they have to pull
    > Linus' tree to know when their changes have been pulled. That may be
    > part of the "fun" aspect that Davem is seeing going away in exchange
    > for more administrative relations. But if we agree that nobody knows
    > all the changes, we must agree that we need tools to track them, and
    > tools are fundamentally incompatible with smart human relations.
    > > In fact, so many changes go in at a time during a merge window, that we often
    > > can't really say which of them causes the breakage observed by testers and
    > > bisection, that IMO should really be a last-resort tool, is used on the main
    > > debugging techinque.
    > Maybe we could slightly improve the process by releasing more often, but
    > based on topics. Small sets of minimally-overlapping topics would get
    > merged in each release, and other topics would only be allowed to pull
    > fixes. That way everybody still gets some work merged, everybody tests
    > and problems are more easily spotted.

    I like this idea.

    > I know this is in part what Andrew tries to do when proposing to
    > integrate trees, but maybe some approximate rules should be proposed
    > in order for developers to organize their works. This would begin
    > with announcing topics to be considered for next branch very early.
    > This would also make it more natural for developers to have creation
    > and bug-tracking phases.

    Yes, that's reasonable.


     \ /
      Last update: 2008-05-01 02:09    [W:0.024 / U:1.588 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site