lkml.org 
[lkml]   [2008]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 72/79] sysdev: Pass the attribute to the low level sysdev show/store function
On Wed, Jul 23, 2008 at 11:03:10AM +0200, Ingo Molnar wrote:
> ok, lemme do a bit of merge window flaming here, in defense of Andrew.
>
> This commit history:
>
> commit 4a0b2b4dbe1335b8b9886ba3dc85a145d5d938ed
> Author: Andi Kleen <andi@firstfloor.org>
> AuthorDate: Tue Jul 1 18:48:41 2008 +0200
> Commit: Greg Kroah-Hartman <gregkh@suse.de>
> CommitDate: Mon Jul 21 21:55:02 2008 -0700
>
> sysdev: Pass the attribute to the low level sysdev show/store function
>
> [...]
>
> I converted all users in tree to the new show/store prototype. It's
> a single huge patch to avoid unbisectable sections.
>
> Runtime tested: x86-32, x86-64
> Compiled only: ia64, powerpc
> Not compile tested/only grep converted: sh, arm, avr32
>
> covers a relatively trivial patch that we'd normally not notice, but it
> is ... a ... misrepresentation of the true situation on several levels:
>
> 1) The changelog. The updated patch Andi sent did not declare the other
> incremental changes (to sched.c) it also included freshly.

Andi's original patch that he sent me _did_ declare that he had updated
the patch, I didn't change the changelog as it didn't make sense to do
so.

> 2) The date. This patch did not originate on Jul 1 - if Andi sent a
> material update yesterday it should say Jul 21, not Jul 1.

Again, my fault, I kept the original email headers and just updated the
patch portion. It's easier for me to do that using quilt, hence the
lack of the date change.

> 3) The justification. Huge atomic patches are fine and can indeed be
> much simpler than a gradual switchover, _iff_ they are done
> perfectly. If there's any doubt then they are by far not the only
> option to pursue - we've done finegrained API changeovers for years.

This kind of API change is atomic, sorry. It was tiny enough that it
didn't justify a big rework (like I did on the recent device_create()
stuff for example) to get it modified.

> ... which all we still wouldnt worry much about (the whole change is
> relatively trivial), if it had been done more carefully without wrecking
> Andrew's workflow in the middle of the merge window.

I understand, and I apologize.

thanks,

greg k-h


\
 
 \ /
  Last update: 2008-07-23 16:11    [W:0.127 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site