Re: [ 00/19] 3.10.1-stable review

From: Ingo Molnar
Date: Fri Jul 19 2013 - 07:10:39 EST



* 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/