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:3.231 / U:0.076 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site