Message-ID: <alpine.LFD.2.02.1206161103320.3086@ionos>
Date:	Sat, 16 Jun 2012 12:50:05 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Greg KH <greg@...ah.com>
cc:	ksummit-2012-discuss@...ts.linux-foundation.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Ksummit-2012-discuss] [ATTEND or not ATTEND] That's the
 question!

On Fri, 15 Jun 2012, Greg KH wrote:
> On Sat, Jun 16, 2012 at 12:56:36AM +0200, Thomas Gleixner wrote:
> > 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?
> 
> That's a very good question, and I've been wondering if someone is
> trying to flood us with crap submissions just to try to DoS us and slow
> us down.  If not, it's an interesting "attack" vector onto our
> development process that we need to be able to handle better.

I don't think it's a DoS attack.

Interestingly enough the embedded folks have pretty much got their
gear together and are activly working on consolidation. They learned
the hard way that just hacking more crap into the code is going to end
in a disaster so they are activly watching out for other people
working in the same area.

The folks who concern me more are in the enterprise space. There are
moments where I start to believe that big corp managers have
established a secret project to implement RFC2795.

While the embedded horror is and was mostly confined in SoC specific
places, the enterprise flood is massivly targeted at the guts of the
core kernel. That makes me increasingly nervous.

> >    - How do we prevent further insanity to known problem spaces (like
> >      cpu hotplug) without stopping progress?
> 
> Progress can slow, if we want it to, in some areas, just to let people
> get the time to fix up the issues we currently have.  That saves time in
> the long run, but requires that someone make it very clear as to what is
> going on and how it will change in the future.

Indeed, but sadly there are not enough maintainers who enforce that
and trying to enforce it is a major challenge.
 
Even if people realize that there is a problem, the "we need to reach
our milestones" mindset doesn't allow them to sit down and help with
fixing it. Though that's not a Linux specific issue, but I wish that
we as the kernel community could find a way to confine this global
braindamage.

I've been doing continous cleanup work in the last decade and enjoyed
it, though I'm starting to get increasingly frustrated and grumpy. It
might be an age thing :) Though talking to Al Viro makes me certain,
that it's not.

A good start would be if you could convert your kernel statistics into
accounting the consolidation effects of contributions instead of
fostering the idiocy that corporates have started to measure themself
and the performance of their employees (I'm not kidding, it's the sad
reality) with line and commit count statistics.

Maybe that would give more people an incentive to care about the big
and long term picture instead of basking in their short sighted "hack
it into submisson" achievements. I know that it's the wrong reason
when they don't realize the real thing themself, but the end justifies
the means :)

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