From: Daniel Walker <dwalker@codeaurora.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org
Subject: Re: [GIT PULL] ARM MSM updates for 2.6.35-rc1
Date: Wed, 02 Jun 2010 15:30:26 -0700 [thread overview]
Message-ID: <1275517826.27006.114.camel@c-dwalke-linux.qualcomm.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1006021413100.8175@i5.linux-foundation.org>
On Wed, 2010-06-02 at 14:27 -0700, Linus Torvalds wrote:
>
> On Wed, 2 Jun 2010, Daniel Walker wrote:
> >
> > Don't forget about this one! Or was something wrong with it?
>
> I got a bit frustrated with ten different ARM pulls per day at one point.
>
> There's something wrong with ARM development. The amount of pure noise in
> the patches is incredibly annoying. Right now, ARM is already (despite me
> not reacting to some of the flood) 55% of all arch/ changes since 2.6.34,
> and it's all pointless churn in
>
> arch/arm/configs/
> arch/arm/mach-xyz
> arch/arm/plat-blah
>
> and at a certain point in the merge window I simply could not find it in
> me to care about it any more.
>
> Do you guys at all talk about this problem? Have any of the ARM people
> bothered to look at the arch/arm diffs and see how mind-deadening they
> are? I try to look through these kinds of things when I pull, but after a
> million lines of pure noise, it gets old pretty quickly.
There's room for the sub-architectures to combine stuff. I think there
is work going on to do that (at some level).
> Somehow, I can't believe that you need thousands of lines for each random
> arch/arm/mach-xyz (yeah, some very few of them are smaller).
I'm not an authority by any means, but every time there is a new device
released (which is often) you get a new file under some mach-xyz
directory, or some large modification to an already existing file. Plus
a config file potentially. It's a little bit like the wild west, and
seems way wilder than x86 every was.
I think from the sub-architecture maintainer perspective the pain is all
hidden behind the Linus curtain , or RMK curtain or the some other
maintainer curtain. So we don't really talk about it that often. I
thought you we're totally happy with the situation ..
If you have some idea's for fixing things, I'm all ears along with my
faithful sub-architecture maintainer brothers.
Daniel
next prev parent reply other threads:[~2010-06-02 22:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-27 21:52 [GIT PULL] ARM MSM updates for 2.6.35-rc1 Daniel Walker
2010-06-02 20:50 ` Daniel Walker
2010-06-02 21:27 ` Linus Torvalds
2010-06-02 21:39 ` Linus Torvalds
2010-06-02 21:56 ` Daniel Walker
2010-06-02 22:30 ` Daniel Walker [this message]
2010-06-02 23:27 ` Kevin Hilman
2010-06-03 1:20 ` Linus Torvalds
2010-06-03 3:44 ` Michael Ellerman
2010-06-03 4:26 ` Linus Torvalds
2010-06-03 16:11 ` Tony Lindgren
2010-06-04 5:34 ` Eric Miao
2010-06-03 4:45 ` Ben Dooks
2010-06-03 5:36 ` Ben Dooks
2010-06-04 8:27 ` Vincent Sanders
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1275517826.27006.114.camel@c-dwalke-linux.qualcomm.com \
--to=dwalker@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).