lkml.org 
[lkml]   [2007]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: x86 status was Re: -mm merge plans for 2.6.23
    On Wed, 11 Jul 2007 19:42:52 +0200 Ingo Molnar wrote:

    >
    > * Andi Kleen <andi@firstfloor.org> wrote:
    >
    > > > clockevents-fix-typo-in-acpi_pmc.patch
    > > > timekeeping-fixup-shadow-variable-argument.patch
    > > > timerc-cleanup-recently-introduced-whitespace-damage.patch
    > > > clockevents-remove-prototypes-of-removed-functions.patch
    > > > clockevents-fix-resume-logic.patch
    > > > clockevents-fix-device-replacement.patch
    > > > tick-management-spread-timer-interrupt.patch
    > > > highres-improve-debug-output.patch
    > > > hrtimer-speedup-hrtimer_enqueue.patch
    > > > pcspkr-use-the-global-pit-lock.patch
    > > > ntp-move-the-cmos-update-code-into-ntpc.patch
    > > > i386-pit-stop-only-when-in-periodic-or-oneshot-mode.patch
    > > > i386-remove-volatile-in-apicc.patch
    > > > i386-hpet-assumes-boot-cpu-is-0.patch
    > > > i386-move-pit-function-declarations-and-constants-to-correct-header-file.patch
    > > > x86_64-untangle-asm-hpeth-from-asm-timexh.patch
    > > > x86_64-use-generic-cmos-update.patch
    > > > x86_64-remove-dead-code-and-other-janitor-work-in-tscc.patch
    > > > x86_64-fix-apic-typo.patch
    > > > x86_64-convert-to-cleckevents.patch
    > > > acpi-remove-the-useless-ifdef-code.patch
    > > > x86_64-hpet-restore-vread.patch
    > > > x86_64-restore-restore-nohpet-cmdline.patch
    > > > x86_64-block-irq-balancing-for-timer.patch
    > > > x86_64-prep-idle-loop-for-dynticks.patch
    > > > x86_64-enable-high-resolution-timers-and-dynticks.patch
    > > > x86_64-dynticks-disable-hpet_id_legsup-hpets.patch
    > >
    > > I'm sceptical about the dynticks code. It just rips out the x86-64
    > > timing code completely, which needs a lot more review and testing.
    > > Probably not .23
    >
    > What you just did here is a slap in the face to a lot of contributors
    > who worked hard on this code :(
    >
    > Let me tell you about the history of this project first.

    ... [lwn.net articles and other quotes snipped]

    > But what is curiously absent from all this positive and dynamic activity
    > around these patches on lkml? There is not a single email from Andi
    > Kleen, the official maintainer of the x86_64 tree directly reacting to
    > this submission in any way, shape or form. Not a single email from you
    > thanking Arjan, Chris and Thomas for this amount of cleanup to the
    > architecture you are maintaining:
    >
    > 31 files changed, 698 insertions(+), 1367 deletions(-)

    Hm, I don't usually get thanks emails. Do other people?

    > Not a single email from you reviewing the patchset in any meaningful
    > way. Not a single email from you to indicate that you even did so much
    > as boot into this patchset.
    >
    > What contribution do we have from you instead? A week before the .23
    > merge window is closed, in the very last possible moment, we finally get
    > your first reaction to this patchset, albeit in the form of three terse
    > sentences:
    >
    > > I'm sceptical about the dynticks code. It just rips out the x86-64
    > > timing code completely, which needs a lot more review and testing.
    > > Probably not .23
    >
    > In the past 3+ months there was not a single email from you indicating
    > that you are "doubtful" about this submission, and that you think that
    > it needs "lot more review and testing". You dont offer any alternative,
    > you dont offer any feedback, no review, no testing, no support, just a
    > simple rejection on lkml that prevents this project from going upstream.
    >
    > Yes, maintainers have veto power and often have to make hard decisions,
    > but, and let me stress this properly:
    >
    > Only if they actually act as honest maintainers!
    >
    > Altogether 197 emails on lkml discussed these patches, and you were
    > Cc:-ed to every one of them. Over a dozen kernel developers reviewed it
    > or reacted to the patchset in one way or another. And your only reaction
    > to this is silence and a rejection claiming that it needs "lot more
    > review"? I'm utterly speechless.

    I can understand being disappointed, but not quite as upset as you
    appear to be.

    so have you (Ingo) reviewed the ext4 patches? or reiser4 patches?
    or lumpy reclaim? or anti-fragmentation?

    I certainly haven't. I can barely keep up with reading about 1/2
    of lkml emails. And in my non-scientific method, I think that we
    are suffering from both (a) more patch submittals and (b) fewer
    qualified reviewers (per kernel KLOC) than we had 3-5 years ago.

    I don't see how you can expect Andrew to review these or any other
    specific patchset. Do you have some suggestions on how to clone
    Andrew?

    ---
    ~Randy
    *** Remember to use Documentation/SubmitChecklist when testing your code ***
    -
    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/

    \
     
     \ /
      Last update: 2007-07-11 23:03    [W:0.051 / U:0.460 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site