From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1767537AbXDFHTL (ORCPT ); Fri, 6 Apr 2007 03:19:11 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1767536AbXDFHTL (ORCPT ); Fri, 6 Apr 2007 03:19:11 -0400 Received: from caramon.arm.linux.org.uk ([217.147.92.249]:2772 "EHLO caramon.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753632AbXDFHTK (ORCPT ); Fri, 6 Apr 2007 03:19:10 -0400 Date: Fri, 6 Apr 2007 08:18:58 +0100 From: Russell King To: Alan Cox Cc: Tony Lindgren , Roland Dreier , Randy Dunlap , linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/90] Post 2.6.21 OMAP update Message-ID: <20070406071858.GC6730@flint.arm.linux.org.uk> Mail-Followup-To: Alan Cox , Tony Lindgren , Roland Dreier , Randy Dunlap , linux-kernel@vger.kernel.org References: <11757088774110-git-send-email-tony@atomide.com> <20070404182728.GK29129@atomide.com> <20070404113925.da221efc.randy.dunlap@oracle.com> <20070404184455.GL29129@atomide.com> <20070404224448.0ff60ed2@the-village.bc.nu> <20070405132144.GC24297@atomide.com> <20070405180334.GW24297@atomide.com> <20070405212713.10675e27@the-village.bc.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070405212713.10675e27@the-village.bc.nu> User-Agent: Mutt/1.4.2.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 05, 2007 at 09:27:13PM +0100, Alan Cox wrote: > > Hmm, yeah I'll see if I could group them a bit. The problem there > > is that the patch series contains multiple rounds of "add and fix" > > cycles. Pretty much all the non-dependant fixes have already been > > applied, BTW. > > Bear in mind that it doesn't work now, so merging some stuff and being in > a "more merged but still not yet a tree to build OMAP from" is not a > regression or a problem. > > Going back some time the PA-RISC merge occurred over several months until > one day it was all there. I think Tony's problem is the volume of changes though - I think it is fair to say that in 2.6.18 it was fully merged and working. Since then, for one reason or another the merge windows got missed (ISTR it was triggered due to me not being able to devote the full 14 days to kernel work during the 2.6.19 merge window due to going on holiday) which has resulted in subsequent merge windows being missed, and therefore the number of changes increasing and the problem Tony's now in. In that respect, if it no longer "work"s now, it's technically a regression. Clearly the real solution is for rmk never to go on holiday during a merge window, but I don't personally find that acceptable. Or maybe human cloning, but I'm sure there's people here who think that one rmk is enough. ;) -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: