[ATTEND or not ATTEND] That's the question!

[Thomas Gleixner <tglx@linutronix.de>]

Dear KS comittee,

like it or not, I really can't convice myself to adjust to the concept
of selfadvertising.

So I stick to the traditional way of proposing topics for KS and let
you decide whether the topic is interesting and my attendance is
required.

As you might know I'm wasting^spending a lot of time to fight the
steady growing insanity in the kernel code base. My current target is
cpu hotplug, but that's just a place holder for a more general
problem.

The steady increasing interest in Linux and the outcome of our quests
to convince involved parties to contribute leads to a few interesting
questions.

Thinking more about it, it all boils down to a single question:

 Are we (the kernel community and the current maintainer setup) able
 to cope with the inflood of patches?

  I for myself (admittedly I'm responsible for too much already, and
  I'm quite sure that other top level maintainers suffer in the same
  way) have a hard time to keep track of all the "interesting" bits
  which hit my inbox.

  Sure one might argue that I should delegate responsibility to others
  to lower my workload.

  I'd be happy to do that, really. I'm not a control freak and I
  really don't care about my patch count statistics (I never did, and
  I wish that this particular idiocy would have never been invented).

  Also I have delegated stuff to a large degree already.
  
  Though I have a hard time to find people who I can trust enough to
  take care of crucial core infrastructure bits.

  Aside of that I see a (steady increasing) repeated pattern that
  potential contributors propose totaly clueless patches to "solve" a
  particular problem.

  The time I spend on talking clue into those folks is at least an
  order of magnitude larger than coding it myself.

  I'm pretty sure that this is not caused by my inabilty to explain
  stuff to those folks, but by the insanity of managers who believe
  that adding a random number of random chosen so called "human
  resources" (I abhor that phrase) will solve the problems at hand.

  I know that the world and this industry in particular is driven by
  such insanities, but I can't commit myself to adhering to that.

So the main questions I want to raise on Kernel Summit are:

   - How do we cope with the need to review the increasing amount of
     (insane) patches and their potential integration?

   - How do we prevent further insanity to known problem spaces (like
     cpu hotplug) without stopping progress?

A side question, but definitely related is:

   - How do we handle "established maintainers" who are mainly
     interested in their own personal agenda and ignoring justified
     criticism just because they can?

Thanks,

	tglx