Date:	Wed, 30 Apr 2008 16:20:29 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Willy Tarreau <w@....eu>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	David Miller <davem@...emloft.net>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Slaby <jirislaby@...il.com>
Subject: Re: Slow DOWN, please!!!



On Thu, 1 May 2008, Willy Tarreau wrote:
> > 
> > Any suggestions on how to convince people that their code is not worth 
> > merging?
> 
> I think you're approaching a solution Linus. If developers take a refusal
> as a punishment, maybe you can use that for trees which have too many
> unresolved regressions.

Heh. It's been done. In fact, it's done all the time on a smaller scale. 
It's how I've enforced some cleanliness or process issues ("I won't pull 
that because it's too ugly"). I see similar messages floating around about 
individual patches.

That said, I don't think it really works that well as "the solution": it 
works as a small part of the bigger picture, but no, we can't see 
punishment as the primary model for encouraging better bevaiour. 

First off, and maybe this is not true, but I don't think it is a very 
healthy way to handle issues in general. I may come off as an opinionated 
bastard in discussions like these, and I am, but when it actually comes to 
maintaining code, really prefer a much softer approach.

I want to _trust_ people, and I really don't want to be a "you need to do 
'xyz' or else" kind of guy. 

So I'll happily say "I can't merge this, because xyz", where 'xyz' is 
something that is related to the particular code that is actually merged. 
But quite frankly, holding up _unrelated_ fixes, because some other issue 
hasn't been resolved, I really try to not do that. 

So I'll say "I don't want to merge this, because quite frankly, we've had 
enough code for this merge window already, it can wait". That tends to 
happen at the end of the merge window, but it's not a threat, it's just me 
being tired of the worries of inevitable new issues at the end of the 
window.

And I personally feel that this is important to keep people motivated. 
Being too stick-oriented isn't healthy.

The other reason I don't believe in the "won't merge until you do 'xyz'" 
kind of thing as a main development model is that it traditionally hasn't 
worked.  People simply disagree, the vendors will take the code that their 
customers need, the users will get the tree that works for them, and 
saying "I won't merge it" won't help anybody if it's actually useful.

Finally, the people I work with may not be perfect, but most maintainers 
are pretty much experts within their own area. At some point you have to 
ask yourself: "Could I do better? Would I have the time? Could I find 
somebody else to do better?" and not just in a theoretical way. And if the 
answer is "no", then at that point, what else can you do? 

Yes, we have personalities that clash, and merge problems. And let's face 
it, as kernel developers, we aren't exactly a very "cuddly" group of 
people. People are opinionated and not afraid to speak their mind. But on 
the whole, I think the kernel development community is actually driven a 
lot more by _positive_ things than by the stick of "I won't get merged 
unless I shape up".

So quite frankly, I'd personally much rather have a process that 
encourages people to have so much _pride_ in what they do that they want 
it to be seen as being really good (and hopefully then that pride means 
that they won't take crap!) than having a chain of fear that trickles 
down.

So this is why, for example, I have so strongly encouraged git maintainers 
to think of their public trees as "releases". Because I think people act 
differently when they *think* of their code as a release than when they 
think of it as a random development tree.

I do _not_ want to slow down development by setting some kind of "quality 
bar" - but I do believe that we should keep our quality high, not because 
of any hoops we need to jump through, but because we take pride in the 
thing we do.

[ An example of this: I don't believe code review tends to much help in 
  itself, but I *do* believe that the process of doing code review makes 
  people more aware of the fact that others are looking at the code they 
  produce, and that in turn makes the code often better to start with.

  And I think publicly announced git trees and -mm and linux-next are 
  great partly because they end up doing that same thing. I heartily 
  encourage submaintainers to always Cc: linux-kernel when they send me a 
  "please pull" request - I don't know if anybody else ever really pulls 
  that tree, but I do think that it's very healthy to write that message 
  and think of it as a publication event. ]

			Linus
--
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