Subject: Re: [patch 00/46] High resolution timer / dynamic tick update
From: john stultz <johnstul@us.ibm.com>
To: Daniel Walker <dwalker@mvista.com>
Cc: Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
       Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>,
       Arjan van de Veen <arjan@infradead.org>,
       Roman Zippel <zippel@linux-m68k.org>
In-Reply-To: <1169671890.19471.309.camel@imap.mvista.com>
References: <20070123211159.178138000@localhost.localdomain>
	 <1169604991.19471.95.camel@imap.mvista.com>
	 <20070124070701.GA17654@elte.hu>
	 <1169631016.19471.175.camel@imap.mvista.com>
	 <1169668653.6905.49.camel@localhost.localdomain>
	 <1169671890.19471.309.camel@imap.mvista.com>
Content-Type: text/plain
Date: Wed, 24 Jan 2007 13:23:32 -0800
Message-Id: <1169673812.6905.71.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1928
Lines: 41

On Wed, 2007-01-24 at 12:51 -0800, Daniel Walker wrote:
> On Wed, 2007-01-24 at 11:57 -0800, john stultz wrote:
> > Thomas' changes are more obviously purpose driven, and Daniel's appear
> > more like just cleanups. So given that, if it were me, I'd put Thomas
> > changes in first, and re-diff Daniel's non-redundant changes on top.
> 
> Seems backwards , clean ups should always go first. If Thomas had
> started off my patch set his changes would have been smaller and
> hopefully stronger. (I even remember you tell me that you wanted the
> kernel/time/timekeeping.c change first in my series cause clean ups
> should go first..)

Well, I suggested the kernel/time/timekeeping.c change go in last cycle,
when you pushed your other cleanups, because that sort of large,
move-tons-of-code patch sucks to keep out of the tree for long as it
would surely collide with something at some point.

> If the HRT changes went in I would have to re-make my cleanups, then do
> more cleanup to change the stuff Thomas is introducing. Looking at his
> code, to do a clean up I would want to just outright revert it.
[snip]
> Given the circumstances I don't see how we can do anything less than
> resolve the conflicts .. My cleanups first, then his code and condense
> and update his set. I'll gladly volunteer to do that.

Hmmm. I just don't quite see the severity of the conflict.

Nonetheless, code talks, so don't let me get in the way, but I really
think patching on top of the HRT queue is the best way forward. 

Even if they revert portions, it clearly points out why your changes
would be better, focusing the discussion, instead of just making a large
alternate patch queue.

-john

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/