Recent searches
Search options
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?
@adamw@fosstodon.org@corbet @bars @marcan@treehouse.systems 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).
@corbet @bars @marcan@treehouse.systems real world example: https://bugzilla.redhat.com/show_bug.cgi?id=2113005 . trying to keep up with what the heck is going on with that bug upstream requires painful searching through awful mailing list archives for patch series with cryptic titles (I actually just wind up searching for maintainer names and wading through pages of unrelated gunk). this could and should be easier.
@corbet @bars @marcan@treehouse.systems there are F/OSS forges: there's the F/OSS core of gitlab, there is Gitea, and there is pagure. None of these is perfect, but they're all there and they work. I'm sure either gitea or pagure would welcome (this is a *massive understatement*) some kernel folks showing up to help maintain and improve them.
My eyes. My eyes.
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 @adamw @bars @marcan That sounds like something the @sovtechfund would cover, if someone applied for it.
@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.
@vegard @corbet @marcan@treehouse.systems
Maybe that "lukewarm response" is because the maintainer is already totally drained for various reasons.
No idea if that's the case, but I guess I would be if I was put in Jon's position, because (1) the work on docs is even less rewarding than other maintainer positions (2) it's a huge amount of work without any financial backing for the maintainer (3) a big rework is needed since years to bring some order into things, but there are no resources in sight for that.
@kernellogger @corbet @marcan Just to be clear, I wasn't singling out Jon here -- it's a complex issue for sure. I think drained contributors and drained maintainers feed back into each other's drain.
What rework/order do you mean? I'm interested in documentation in general. I've tried cleaning up the documentation front page before and it went nowhere. I'd be happy to take a stab at fixing things but what's the maximum ROI thing I can do that has a chance of actually making a difference?
@vegard @corbet @marcan@treehouse.systems
"[…] feed back into each […]" Yup… 
"What rework[…]" I got the feeling that Jon would like to do a lot of things if he'd time, but maybe I'm wrong with that.
If I'd be in his shoes, I feel like there is a massiv amount of work waiting to be done, like
- cleaning up old, obsolete stuff
- remove dups (Documentation/process/submitting-patches.rst vs. Documentation/process/[1-8].*.rst)
- separation of content by target audience (users, userland devs, kernel devs, …)
@kernellogger @vegard @corbet @marcan People who are "totally drained" should quit. Or at least take a long hiatus. Especially if it means they can't do their job properly.