[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20091103223433.23765578.akpm@linux-foundation.org>
Date: Tue, 3 Nov 2009 22:34:33 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Johannes Berg <johannes@...solutions.net>
Cc: Marcel Holtmann <marcel@...tmann.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
David Miller <davem@...emloft.net>,
torvalds@...ux-foundation.org, linville@...driver.com,
linux-kernel@...r.kernel.org, linux-wireless@...r.kernel.org
Subject: Re: Please consider reverting
7d930bc33653d5592dc386a76a38f39c2e962344
On Tue, 03 Nov 2009 08:44:59 +0100 Johannes Berg <johannes@...solutions.net> wrote:
> On Tue, 2009-11-03 at 16:16 +0900, Marcel Holtmann wrote:
>
> > and can we please stop jumping the gun here and going past the subsystem
> > maintainers. I think this happens a little bit too much lately.
>
> I'll rant a bit too -- I've been very annoyed by this many times.
Problem is, subsystem maintainers are very unreliable.
Right now I'm sitting on 17 patches which I think should be in 2.6.32,
which I need to plead with subsystem maintainers to take a look at.
They've already seen the patches (usually at least twice) and they've
just blown them off. This is typical.
And then there are the 100 to 200 non-critical patches which I'm always
sitting on, similarly ignored. And I'm increasingly just ignoring
stuff nowadays because this situation is so bad.
And then there are all the bug reports which flow in one ear and out
the other.
Now, some subsystem maintainer are good, and some aren't. I'm probably
the only person who could write the detailed list for each column.
Unfortunately, people who have better lives than me are best off
assuming that a subsystem maintainer is unreliable. If the problem is
severe enough, bypassing the maintainer is a sensible default.
--
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