|
For me, this is one of the most interesting aspects to the development of Linux, and one I've been studying for years at various levels. Even though I don't understand a lick of most of the code, watching the lkml and the process itself is very quite interesting, however, there are a few ways to try and put the kernel in a better position in the future. Each major release can be considered a "story", for example, the journey of WireGuard from inception to submitting it to the kernel, that's an entire process, involving many, many steps and employs an unlimited number of tools; meeting in person, email, VoIP, Slack and anything you can think of. Conversations that turn into code are a vital part of kernel development, but I feel is less well known (after all, we just see code shuffling about git repos). Each bit of code is possibly hours of work, represents many conversations, and yet, git cannot (and does not), preserve the history of how code reaches Linus' tree. So, how can we improve this situation? Document, document, document!! I'd love to see someone like Greg Kroah-Hartman, David Miller, Stephen Rothwell et al document, extensively, how they do their work. I'm talking about high resolution; screen captures, text, images, audio and anything else that we can preserve going forward, perhaps all neatly tucked away in a git repo and backed up many, many times. Seriously, we're at risking of losing a core vital understanding of how people do their work, especially those who are core to the Kernel. Of course, people may develop new methods, but I feel the kernel is quite mature and the processes in theory are quite stable too (such as how Greg actually releases a stable kernel once a week). Of course, not everything can be documented, older software gets older, and someone's favorite email client may not be transferable, but the general process can be. So yes, this is something to think about and prepare for, otherwise it may hit the kernel quite hard. |