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    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site