[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070425143011.57247c1d.akpm@linux-foundation.org>
Date: Wed, 25 Apr 2007 14:30:11 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Randy Dunlap <randy.dunlap@...cle.com>
Cc: Martin Schwidefsky <schwidefsky@...ibm.com>,
linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org,
mb@...sch.de, linville@...driver.com, arnd@...db.de,
maxextreme@...il.com, gregkh@...e.de
Subject: Re: [PATCH 0/9] Kconfig: cleanup s390 v2.
On Wed, 25 Apr 2007 11:21:33 -0700
Randy Dunlap <randy.dunlap@...cle.com> wrote:
> On Mon, 23 Apr 2007 10:45:34 -0700 Andrew Morton wrote:
>
> > On Mon, 23 Apr 2007 16:11:23 +0200
> > Martin Schwidefsky <schwidefsky@...ibm.com> wrote:
> >
> > > Greetings,
> > > I've added the results of the review to the Kconfig cleanup patches
> > > for s390. Patch #2 has been split, one half has all the HAS_IOMEM
> > > depends lines the other the remaining !S390 depends lines.
> > >
> > > Andrew: I plan to add patches 1-5 to the for-andrew branch of the
> > > git390 repository if that is fine with you. The only thing that will
> > > be missing in the tree is the patch that disables wireless for s390.
> > > The code does compile but without hardware it is mute to have the
> > > config options. I'll wait until the git-wireless.patch is upstream.
> > > Patches 7-9 depend on patches found in -mm.
> > >
> >
> > umm, OK. If it's Ok I think I'll duck it for now: -mm is full.
> >
> > Over-full, really: I've been working basically continuously since Friday
> > getting the current dungpile to compile and boot, and it's still miles away
> > from that.
>
> and I continue to be concerned about the amount of patch reviews
> compared to new patch material overall (not just s390).
>
yes. I'm increasingly reluctant to merge things which have had no visible
review from any third party. Nowadays I'll shove such patches into a
pending folder and will wait a day or three to see if anyone has any
feedback. If they don't I have to either ignore the patches or review them
myself.
I expect (and hope) that more formal processes will come about here. Perhaps
up to it-won't-be-merged-without-a-Reviewed-by:.
But that only applies to things which I merge. There's heaps of stuff
coming in via the git trees which is obviously inadequately reviewed - look
at all the instances of open-coded kernel_thread() which were merged after
the kthread() API was introduced, for example.
And other basic stuff like "use mutexes, not semaphores":
box:/usr/src/25> grep '^+.*[ ]down[ ]*[(]' patches/git-*.patch | wc -l
32
Ever wonder where all those whitespace bugs are coming from?
box:/usr/src/25> grep '^+.*[ ]if[(]' patches/git-*.patch | wc -l
265
box:/usr/src/25> grep '^+.*[ ]while[(]' patches/git-*.patch | wc -l
35
Code which use spaces where it should be using tabs?
box:/usr/src/25> grep '^+ ' patches/git-*.patch | wc -l
1346
Heaven knows how many more serious problems are being snuck into the tree
via this route.
What do we do?
-
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