linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).