How patches get into the mainline

"In the latter case, the more persistent developers would resend the patch. Often, developers had to be persistent indeed if they wanted their code to be merged. The system was, in other words, lossy; we'll never know how much useful code was simply dropped.

"The use of git (and BitKeeper before it) has brought an end to that era. Once a change gets into somebody's tree, it is relatively unlikely to be lost. It's a much better way of doing things for everybody involved; important fixes no longer get lost, and developers, rather than checking for their patches and resending them, can now devote themselves to the creation of new bugs to be fixed.

"Beyond that, though, things have changed in that, for most developers, the way to get a patch into the kernel is no longer to send it to Linus. Instead, they will pass their work through a subsystem tree. This mechanism is reasonably well understood, but, to your editor's knowledge, nobody has taken a hard look at what the flow of patches into the mainline looks like now. With that in mind, your editor set out with the complementary goals of (1) charting the paths patches take on their way to Linus, and (2) figuring out how Graphviz works. A certain amount of success was achieved on both fronts."

Complete Story

Related Stories:

• Wakelocks and the embedded problem(Feb 24, 2009)
• The new GCC runtime library exemption(Feb 08, 2009)
• LCA2009: That mysterious thing called the kernel(Jan 21, 2009)
• Linus Torvalds on regression, laziness and having his code rejected(Jan 21, 2009)
• MinGW and Why Linux Users Should Care(Dec 10, 2008)
• The Sad Story of the em28xx Driver(Nov 24, 2008)
• Fedora Moves the X Server(Oct 31, 2008)
• Linux-Kongress: Corbet Presents New Kernel 2.6.27(Oct 11, 2008)