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

[Ingo Molnar <mingo@elte.hu>]

* 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. Arjan wrote the 
first version of it a year ago, and it was added to -rt and tested there 
by many people and went through many iterations and fixes. Chris Wright 
then created a x86_64 clockevents cleanup and dynticks enabling patchset 
from it this spring and sent it to lkml three and a half months ago, on 
March 31:

    http://lwn.net/Articles/229094/

Thomas, the high resolution timers and clockevents maintainer, 
immediately picked up Chris' splitup/splitout/cleanup work and fixed and 
extended it, and sent a first cut to lkml on May 6th:

    http://lwn.net/Articles/233226/

Thomas then sent an updated version of the x86_64 clockevents cleanup 
and dynticks code to lkml (on June 10th), for a second round of review:

    http://lwn.net/Articles/237687/

As Thomas stated it in his submission:

  " The patch set has been tested in the -hrt and -rt trees for quite a 
    while and the initial problems have been sorted out. Thanks to the 
    folks from the PowerTop project for testing and feedback. "

Then on June 16th Thomas sent the third series:

    http://lwn.net/Articles/238834/

(which too was in -rt and was tested there on numerous machines. It was 
also added to -mm.)

Then on June 23rd Thomas sent the fourth series of the x86_64 
clockevents and dynticks code:

    http://lwn.net/Articles/239620/

We finally have someone (Thomas) with core kernel clue who actually 
_cares_ about the x86 time code and does not see it as an ugly chore, 
one who collects the right patches and maintains the -hrt tree and 
co-maintains the -rt tree and interacts with other contributors. What he 
did was _hard_ to do but we are making really good progress:

   http://lkml.org/lkml/2007/7/5/242

   " All in all, personally I'm very happy to see Linux making such a 
     huge step forward with tickless and can't wait for this step to be 
     available in all distros and for all architectures... "

Yes, touching the time code is a pain because both the hardware and the 
kernel has skeletons hidden in the closet, but we are mapping them one 
by one, and we already fixed several kernel skeletons in the process. 
The code is in -mm and there is no open regression related to this queue 
of patches at the moment.

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(-)

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.

	Ingo