@marcan@bars One of the worst things about working in the kernel — one of the most toxic parts — is the constant stream of nastiness toward our community that comes from outside.
The kernel community is far from perfect; we have a lot of problems and we have been actively working for years (decades) to improve on them.
We are, nonetheless, a project that manages to incorporate nearly 100,000 commits per year, from over 5,000 developers, into a single code base while maintaining a level of quality that — while also certainly in need of improvement — is good enough for deployment into billions of devices.
As for the use of email...email is painful and broken, but we have found nothing better that will work at the scale we need. See https://lwn.net/Articles/702177/ from a few years back. For all its faults, email is distributed, non-proprietary, scriptable, and gives everybody the freedom to choose their tools; it is a highly inclusive solution in a way that proprietary web forges (for example) are not. Someday we'll find something better and move on with a cry of joy, but that day has not come.
Rather than crapping on the kernel community from afar, why not work with us to try to make things better?
@corbet "Of the 5,000 developers who work on the kernel each year, not a single one of them is tasked with documentation"
Do you mean full time? All Oracle Linux kernel devs have an explicit mandate to work on upstream docs. I'm by no means a frequent contributor, but I've submitted a few patches; most of them got rather lukewarm responses at best. I think this actually ties in with what @marcan says: it's draining and not very rewarding when you have to fight for every attempted change.
@adamw@bars@marcan Bug tracking is clearly a place where the kernel project falls down badly, agreed. We finally got regression tracking funded, but that's just barely the beginning of the problem.
For bug tracking, one aspect of the problem is a simple unwillingness on the part of many maintainers to bother with a bug tracker. That does not help at all.
The other part is something I'm going to poke people at the LF shindig about next week. Almost everybody who works on the kernel is paid to do it, but there are many areas that no company thinks it needs to worry about funding. Of the 5,000 developers who work on the kernel each year, not a single one of them is tasked with documentation — my own pet peeve. But (almost) nobody is paid to work on tools, and it hurts us in all kinds of ways, including bug tracking.
@corbet@bars@marcan I think Hector can be a bit strident in his messaging, but I don't think he's *wrong*. From my perspective (Fedora QA) the kernel is one of the things that makes me sigh the most. Just about every other project I deal with - which is, like, nearly all of them - makes it easier to file and find bug reports, follow the progress of debugging and fixing them, and submit and follow pull requests (or whatever the system they use call it).
Compiling without assistance from bug wranglers, doc writers and designers is like trying to do a DnD campaign called "woops all rouges"
The impact of Nathan Lee, Suv and now Krlr on inkscape's development has been monumental. None are developers, all kept the issues tracker producing actionable and detailed reports. But all were volunteers.
The ecological failure in foss can be solved, but not with dichotomised economics. Who pays matters. Who says matters.
@doctormo@corbet@bars@marcan true, but it's not just that. my job is QA but I spend a lot of time coding. I've written fixes for GNOME, KDE, and hundreds of other projects. it is *much* easier to do drive-bys for projects with decent issue tracking and an understandable pull request system with CI hooked up to it (so I know my fix isn't totally busted). the kernel is extremely resistant to drive-by contributions. obviously this is partly due to its nature, but only *partly*.
I think it is reasonable to object to "from outside". marcan is literally a seasoned kernel maintainer. I don't think he needs to be explained what the scale of kernel dev is.
This is a meaningless non-defense of the status quo.
For example, what if there was a forge using open software for each subsystem? You could then integrate whatever tooling you'd like with it.
Bram (rip) made an email based workflow on top of GitHub for vim e.g.. It can be done.