3 ms·

I've heard before from multiple voices that the LKML has a bit of an "old boys club" issue when it comes to accepting contributions. Basically from what I can

I've heard before from multiple voices that the LKML has a bit of an "old boys club" issue when it comes to accepting contributions. Basically from what I can tell, the kernel is so large that you have individual maintainers responsible for a specific tree. Those maintainers in turn basically run their own little fiefdom in terms of what contributions they accept and even how they accept them. Some demand the use of git send-mail like in the olden days, others use a more dedicated website for contributors to upload their patches to (forgot the domain). The problem is that a good chunk of those maintainers are apparently running roughshod in terms of basic decency or willingness to communicate with people submitting patches. Prospective contributors have been yelled at or had their patches rejected for bugs that weren't in code they introduced (but were in the git diff they exported into send-mail) or for fixing a bug that their code relied on while adding a new feature (because it "should've been a separate patch"). It's not all of them, but enough to be frustrating. As for reimplementing submitted patches rather than offering feedback on existing ones and refusing the proper credit - this doesn't surprise me in the slightest, nor does the offense being taken suprise me. This is pretty much the exact same situation that led to the disastrous ffmpeg and avconv forking situation (where the lead maintainer would often not bother giving feedback and reimplement entire PRs on his own, without care for the other person involved). Seeing that replicated is unlikely given its Linux, but bad maintenance does usually follow a few trends. There's a reason that when you get to more "niche" hardware combos like say, homebrewed videogame consoles, most projects don't bother upstreaming to begin with, even if their patches are otherwise quality work. Not everyone wants to deal with these sorts of LKML politics.

toyg 3y ago
LKML has always been a pit. In 2001 already, it was assumed that posting on it as a new contributor would involve surviving a barrage of sneer and abuse. Part of it was just the culture around C communities since at least the early '90s, "l33t h4x0rz" and all that; part was Torvalds himself enjoying the occasional public humiliation a bit too much. It's probably much worse now that there is big money at stake. As for maintainers "taking and rewriting", that has happened since the beginning of free software, the tales of "XXX took my patch and rewrote it, without crediting me in any way" are legion. It's why "Reported-By" was belatedly added, because the phenomenon is so endemic that doing nothing looks bad. But it still happens every day in all sorts of projects, not just Linux.
- mattbee 3y ago
  I made a feature contribution to Xen years ago that ended up with a few lines in the kernel. Got merged pretty promptly but no credit that I can find. I didn't notice at the time but now I'm job hunting, past credits seem a bit more important.
thrtythreeforty 3y ago
My interactions have not been so negative. In particular Greg Kroah-Hartman is a saint for helping me get acquainted with kernel development by providing very patient feedback as I contributed a series of patches. Other maintainers have been similarly responsive, though the tone is typically "very technical feedback from a busy person" rather than new-developer-relations. These people receive patches of random quality, often from one-shot contributions. Triage of the patch stream must be pretty exhausting. I completely understand why people want their name on a kernel patch - it's pretty cool and a good thing to have on a resume - but at the same time, the bar for contributing is quite high and I think the dev process should not optimize for newbie contributors.

toyg 3y ago

LKML has always been a pit. In 2001 already, it was assumed that posting on it as a new contributor would involve surviving a barrage of sneer and abuse. Part of it was just the culture around C communities since at least the early '90s, "l33t h4x0rz" and all that; part was Torvalds himself enjoying the occasional public humiliation a bit too much. It's probably much worse now that there is big money at stake. As for maintainers "taking and rewriting", that has happened since the beginning of free software, the tales of "XXX took my patch and rewrote it, without crediting me in any way" are legion. It's why "Reported-By" was belatedly added, because the phenomenon is so endemic that doing nothing looks bad. But it still happens every day in all sorts of projects, not just Linux.

mattbee 3y ago
I made a feature contribution to Xen years ago that ended up with a few lines in the kernel. Got merged pretty promptly but no credit that I can find. I didn't notice at the time but now I'm job hunting, past credits seem a bit more important.

thrtythreeforty 3y ago

My interactions have not been so negative. In particular Greg Kroah-Hartman is a saint for helping me get acquainted with kernel development by providing very patient feedback as I contributed a series of patches. Other maintainers have been similarly responsive, though the tone is typically "very technical feedback from a busy person" rather than new-developer-relations. These people receive patches of random quality, often from one-shot contributions. Triage of the patch stream must be pretty exhausting. I completely understand why people want their name on a kernel patch - it's pretty cool and a good thing to have on a resume - but at the same time, the bar for contributing is quite high and I think the dev process should not optimize for newbie contributors.