Conflict over a code

Er... You do realize that Linus is not on l-k? As in, had not been subscribed to it for years and if you want him to see some mail, you'd better Cc or forward to him.

The same goes for a lot of active developers; personally, I still hadn't unsubscribed, but I end up deleting unread considerably more than 90%.

These days l-k is more of a public archival mechanism; way back then it used to function as a primary development list, but that role had already been on decline back when I first subscribed to it ('98 or so). A lot of development threads get Cc'ed there, as a courtesy and for archival purposes, but that's it. More specialized lists are different (fsdevel, linux-arch, netdev, etc.), but l-k proper is too high-volume for that.

So complaints about "LKML toxic culture" sound somewhat quaint, to be honest...

BTW, speaking of the thread where the patch from dunlapg had been discussed and accepted - he had some reasons for being annoyed in that thread, but not by emotional abuse (check yourself, it's on https://groups.google.com/forum/#!topic/linux.kernel/XIEi...; everyone had been nice and polite by any possible standards). But having the patches sit uncommented for 4 weeks total *is* annoying. The bottleneck is neither on the producing side (there's a lot of contributors and they send a lot of stuff) nor in merge bandwidth (bk had helped and git had pretty much resolved that one); it's in the bandwidth of _reviewers_. Had been that way for more than a decade now.

And getting more contributions would do nothing to alleviate that bottleneck, obviously. FWIW, last year I had been on the receiving end of rather indignant comments about the inferior workflow of the kernel developers. With python, of all things, being offered as an example of How To Do It(tm). Question that had really changed the tone of the discussion was simple - "how will your superior workflow scale to <that many> commits per month and <that many> contributors?" Both being a _lot_ more than in python git repository...

It's not that we don't need the contributions or would rather have fewer folks contributing, but that's _not_ where the worst shortage is. If the submission rate would double, we would almost certainly hit a serious crisis - most of us often have long queues of things to review and integrate as it is and doubling the inflow would flat-out exceed the available bandwidth in a lot of places.

What we need is more reviewers familiar with the kernel and it takes a while to become such ;-/ I really wish more newbies would pick an area and start RTFS looking for bugs and learning the things in there - would be a lot more useful than ten thousand first patch tweaking the amount of whitespace, both for them and for us. Oh, well...

The claim that the reputation of Linux kernel mailing lists is much, much worse than the reality is true, based on my personal experience. The problem is that the reputation may scare potential contributors away even when it is undeserved. Rather than wring our hands over bad tabloid coverage (LWN excepted!), the question is what to do about it. While the CoC seems about right for the actual situation within the kernel, it won't help us win the publicity war.

I do think that there are particular maintainers who tend to be abusive. If one were to criticize Linus' leadership, it might be to wish that he should rein in those individuals. (Don't go scrutinizing my patches, as maintainers have been unfailingly polite and encouraging to me.)