Re: [PATCH 72/79] sysdev: Pass the attribute to the low levelsysdev show/store function

[Greg KH]

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@xxxxxxxxxxxxxx>
>   AuthorDate: Tue Jul 1 18:48:41 2008 +0200
>   Commit:     Greg Kroah-Hartman <gregkh@xxxxxxx>
>   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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/