[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.0.98.0704261716270.9964@woody.linux-foundation.org>
Date: Thu, 26 Apr 2007 17:22:18 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Thomas Gleixner <tglx@...utronix.de>
cc: Adrian Bunk <bunk@...sta.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.21
On Fri, 27 Apr 2007, Thomas Gleixner wrote:
>
> Maybe we need to coordinate changes better. 2.6.21 got three big updates
> which affected suspend/resume - one of them is my fault. But fiddling
> out which one of those - we had nested problems as well - makes it quite
> hard to grok them in time, especially if they happen only on one
> reporters system.
Yes. _If_ we had known how painful the timer changes would end up being,
we'd probably have done them separately from everything else.
That is the kind of thing that looks obvious in hindsight: merge stuff
that is questionable and scary alone, and don't do anything else that
release cycle.
But while the timer code is obviously pretty core, I think everybody
expected it to be a lot easier to merge (and it had existed as patches in
various forms for some time).
So we simply didn't know beforehand that it was going to cause the kinds
of regressions it did cause (and in fact, some of the regressions were
initially blamed on other things entirely - some of them looked like IO
regressions).
Water under the bridge. It's also easy to say in hindsight that something
should have been merged separately and been given a release cycle all its
own.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists