Re: [ 00/19] 3.10.1-stable review

[Ingo Molnar]

* Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote:

> On Tue, Jul 16, 2013 at 03:12:45PM -0700, Linus Torvalds wrote:
> > I react very strongly when somebody argues against fixing regressions.
> > Let's just say that there's too many years of baggage that I carry
> > around on that issue..
> > 
> > So that is definitely one of the things that make me go ballistic.
> > Buggy code isn't actually one of them. Bugs happen. Even really stupid
> > bugs happen, and happen to good people. They had a bad day, or it was
> > just a brainfart.  Not that I will be _polite_ about bad code, mind
> > you, and there might be some bad words in there, but it doesn't make
> > me blow up.
> > 
> > Being cavalier about known regressions is definitely the primary
> > trigger. I suspect there are others, but I can't seem to recall any
> > other particular hot-button issues right now. Maybe Sarah can post a
> > few more pointers..
> 
> Hmm... The only thing I can think of off the top of my head is that you 
> tend to hate it when someone puts the needs of their particular 
> architecture or distro at a higher priority than the needs of the kernel 
> community.  If they start to push crap code late in the merge window to 
> further their personal goals, you tend to blow up at them.  See the 
> 'deep throat' comment on the PE binary signing thread, for instance.
> 
> The timing of when incidents happen also seems to effect whether you get 
> triggered.  I suspect most of the incidents of you "blowing up" at 
> people happen during the merge window.

Of course timing matters:

 - there are times when a bad pull request can have worse effects, such as 
   shortly before -rc1 or shortly before -final - when many people will be 
   exposed to a new kernel for the first time.

 - timing can also sometimes show a certain level of dishonesty on the 
   developer's side: trying to slip in a bad tree near the end of the 
   merge window, before people can complain it ...

 - there are times when Linus naturally more vulnerable to not having 
   enough time to think things through: such as when he is pulling a dozen 
   trees per day, during the merge window.

Dishonesty, bad timing, running a bad Git flow and making irreversible ABI 
mistakes [of which refusing to fix app regressions is one sort] are all 
hot button issues for Linus, and it's a pretty natural list I think: 
because they are the least actionable, most persistent and thus riskiest 
"meta" problems possible in a kernel project.

Some of Linus's "worst" flames had two or more of these hot button issues 
mixed together. Sometimes a maintainer can get away with a mistake (most 
likely Linus does not notice the mistake) but in general it's all pretty 
consistent.

All in one, with all due respect, I don't think your complaints voiced so 
far against Linus have much merit :-/ I think you'll experience it first 
hand once you become a top level maintainer.

Having said that, I do share your concern that women are more offput by 
the widespread 'manly' talk on lkml: LKML is filled with testosterone. I 
think your solution to create a separate culture is a good one - and 
eventually the two cultures will counter-balance each other in a good way 
and will maybe merge. I cannot think of a better solution either, and I 
fully support your efforts: it's one of the big unsolved problems of Linux 
kernel development.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/