[Ksummit-2009-discuss] Meeting userspace requirements

Theodore Tso tytso at mit.edu
Sun Jul 12 14:00:50 PDT 2009


On Sun, Jul 12, 2009 at 08:01:29AM -0700, Dirk Hohndel wrote:
> On Sun, 12 Jul 2009 06:41:50 -0700
> James Bottomley <James.Bottomley at hansenpartnership.com> wrote:
> 
> > On Sun, 2009-07-12 at 07:29 -0400, Theodore Tso wrote:
> > > The reason why I like this taxonomy is I think it helps explain why
> > > certain ideas/request for implementations/patches get treated the way
> > > that they do, and if people understand this, then perhaps they'll
> > > understand that if they get treated a certain way, it's not because
> > > people are mean-spirited or malicious, but because we get these are
> > > the natural mechanisms which have evolved over time to filter out bad
> > > designs, bad code, and crackpots.  
> > 
> > Sure, this taxonomy will do as well.
> 
> I actually like Ted's taxonomy, especially as it explains how the
> community does not treat ideas equally or fairly at all - a big chunk
> of the likely response depends where it comes from and who speaks up
> for it. Which makes this mechanism fairly easy to manipulate.

Manipulate is such an ugly word...  funny thing, though, there was a
very interesting NPR show that addresses this point that I listed to
very recently.  The title of the episode was "The Science of Trust:
Economics and Virtue", from the show, "Speaking of Faith".

http://speakingoffaith.publicradio.org/programs/2009/neuroeconomics/
http://speakingoffaith.publicradio.org/programs/2009/neuroeconomics/transcript.shtml
http://download.publicradio.org/podcast/speakingoffaith/programs/2009/07/08/20090709_neuroeconomics_128.mp3

One of the points made by the guest, Paul Zak, a professor of
economics at Claremount Graduate University, is that trust is a key
determinate of determining high performing versus low performing
societies is trust.  Quoting from the transcript:

   "What that means is that we don't need a policeman and a lawyer in
    every transaction, and that's great, because now, just like these
    high-trust countries that I spoke of before, we can effect
    transactions quite readily and easily. So the cost in engaging in
    transactions is lower, more transactions occur, and we have more
    wealth creation and greater prosperity. There are downsides to
    that. For example, people will find loopholes and try to exploit
    them, which certainly people of the finance industry did. But by
    and large, I think having these decentralized economies that are
    based on most people most of the time being moral, being
    reciprocal, means that we can do lots of things we couldn't do
    otherwise."

Let's apply this to Linux kernel development; if we blindly accept
every random patch that some crackpot tries submitting, the whole mess
would be come unmaintanable and unreliable very quickly.  Yet if we
subject each of the 563 patches personally authored by Ingo between
2.6.29 and 2.6.30 to the same degree of scrutiny that an unknown
developer submitted, we'd never be able to maintain our development
rate.  So the fact that we could be subject to manipulation is, I
would argue, a necessary evil --- just as the fact that I can
relatively fearlessly invest money in a stock fund, also occasionally
a Bernie Madoff comes along; the two are basically two faces of the
same coin.

That doesn't mean that we shouldn't detect cases where the system has
been "manipulated", and if a core maintainer abuses the trust the
community has placed in him to hide or circumvent reviews with the
result of getting something which is technically deficient or actively
malicious, we want to be able to find him or her, and then make sure
that everyone knows of that breach in trust.   

> > But both of our taxonomies miss one of the cultural impediments of LKML:
> > The desire to demonstrate worth by flaming someone to a crisp.  The
> > mechanical syntax checkers make it all to easy for someone to feel like
> > they've just been ripped to shreds in public just because they didn't
> > know we have style checkers (and the flamer did) --- with no actual
> > substantive discussion of the patch.  A lot of the time, a maintainer
> > can see what's going on and does intervene ... but they have to notice
> > first; this is where the firehose effect of LKML is most detrimental.
> 
> That's a great observation - this happens quite regularly; but how do
> we solve the problem? Is this actually a problem where the community
> behavior is wrong or is this an indication of a problem with the
> submitter / submitted code? 

The desire to filter out bad code or bad design is legitimate.  The
fact that some people do it by flaming someone to a crisp is, in my
opinion, highly unfortunate.  I believe it's because we are so fearful
of accepting bad code or bad design that we don't speak out when
someone goes beyond the line of a rigorous review of a proposed code
or design to outright flaming.  Worse yet, sometimes this happens when
the code/design is _clearly_ bad, and so we egg on the people who
flame the bad idea to the crisp, and not realizing that it disuades
people with legitimate ideas from participating.

> So maybe it is fair to say that someone who gets fried to a crisp over
> simple style / syntax issues hasn't really spent a lot of time preparing
> for their submission? It's not a nice way to deal with this, but it's
> effective (and I say this as someone who had it happen to him on a
> triviality...)

I will admit to occasionally getting frustrated and going flaming
someone a polite, "could you please try running checkpatch.pl and
reading through the checklists in the kernel documentation".
Ultiumately I think we need to take responsibility to remind each
other to be nicer in how we interact with people who are submitting
patches.  It's often not the content of the message that is the
problem, but the tone of the message which is the problem.

						- Ted


More information about the Ksummit-2009-discuss mailing list