Re: x86 status was Re: -mm merge plans for 2.6.23

[Randy Dunlap <rdunlap@xenotime.net>]

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/