lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 16 Jun 2012 00:56:36 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	ksummit-2012-discuss@...ts.linux-foundation.org
cc:	LKML <linux-kernel@...r.kernel.org>
Subject: [ATTEND or not ATTEND] That's the question!

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ