From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [GIT PULL] omap changes for v2.6.39 merge window Date: Fri, 1 Apr 2011 14:41:38 +0200 Message-ID: <201104011441.38902.arnd@arndb.de> References: <20110331130123.GB17547@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Bill Gatliff Cc: Russell King - ARM Linux , Catalin Marinas , Alan Cox , Nicolas Pitre , Dave Airlie , david@lang.hm, Linus Torvalds , Tony Lindgren , David Brown , lkml , linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org List-Id: linux-omap@vger.kernel.org On Thursday 31 March 2011, Bill Gatliff wrote: > On Thu, Mar 31, 2011 at 8:01 AM, Russell King - ARM Linux wrote: > > Just look at the removal of AAEC2000, LH7A40x and 2000 lines from the > > mach-types file removed 6000 lines, which in itself is about the number > > of lines of change submitted during the last merge window for any one > > non-ARM architecture. At this point in time with this complaint, I've > > absolutely no idea why I bothered to do that. I should've left it well > > alone and then the diffstat percentage would've been smaller. After > > all, it's "pointless churn". > > I think you did it because it was the Right Thing To Do. Even > positive change can be painful at times. > > The majority is exceedingly grateful for the effort you make. Defintely. I haven't seen anyone in this thread blame Russell for the mess. As far as I'm concerned, the code in arch/arm consists of the well-maintained {mm,kernel,lib,common,tools,include} directories that are actively being taken care of by Russell, and a huge amount of crap that has accumulated in mach-* and plat-*. Some of it is arguably better than other parts, but the problem is not that someone in particular did a bad job writing the code. The problem is that nobody today is pushing back hard enough on crap getting added. There is a lot of good work going on to reduce the amount of crap in the mach code, but my feeling is that it's not keeping up with the rate of crap getting added by other people. In some ways, the Linaro project has actually made this worse by helping people get their code into shape for inclusion (which of course is generally a good thing to do). Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Fri, 1 Apr 2011 14:41:38 +0200 Subject: [GIT PULL] omap changes for v2.6.39 merge window In-Reply-To: References: <20110331130123.GB17547@n2100.arm.linux.org.uk> Message-ID: <201104011441.38902.arnd@arndb.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thursday 31 March 2011, Bill Gatliff wrote: > On Thu, Mar 31, 2011 at 8:01 AM, Russell King - ARM Linux wrote: > > Just look at the removal of AAEC2000, LH7A40x and 2000 lines from the > > mach-types file removed 6000 lines, which in itself is about the number > > of lines of change submitted during the last merge window for any one > > non-ARM architecture. At this point in time with this complaint, I've > > absolutely no idea why I bothered to do that. I should've left it well > > alone and then the diffstat percentage would've been smaller. After > > all, it's "pointless churn". > > I think you did it because it was the Right Thing To Do. Even > positive change can be painful at times. > > The majority is exceedingly grateful for the effort you make. Defintely. I haven't seen anyone in this thread blame Russell for the mess. As far as I'm concerned, the code in arch/arm consists of the well-maintained {mm,kernel,lib,common,tools,include} directories that are actively being taken care of by Russell, and a huge amount of crap that has accumulated in mach-* and plat-*. Some of it is arguably better than other parts, but the problem is not that someone in particular did a bad job writing the code. The problem is that nobody today is pushing back hard enough on crap getting added. There is a lot of good work going on to reduce the amount of crap in the mach code, but my feeling is that it's not keeping up with the rate of crap getting added by other people. In some ways, the Linaro project has actually made this worse by helping people get their code into shape for inclusion (which of course is generally a good thing to do). Arnd