Zack's Kernel News
What Is Staging?
Greg Kroah-Hartman recently offered some clarification on the nature of the "Staging Tree" because its role had changed; also, there seemed to be some confusion about it.
The staging tree, he explained, was the drivers/staging directory in the official kernel. Code submitted to that directory in the linux -next git repository would be fed directly to Linus during the merge window and would be included in the next official kernel release with little or no objection from him.
Appropriate projects for staging are drivers and filesystems that require no code changes anywhere else in the tree (i.e., they are standalone patches). The only exceptions to this are: firmware can (and should) live in the firmware directory, symbols may be exported from the main kernel code if the relevant subsystem maintainer approves, documentation may live in the Documentation directory, although that is frowned upon.
The value of putting code into staging is that it exists in the main kernel tree; therefore, it has the full universe of kernel users available to test it while presenting minimal danger to kernel stability. It answers a need that has been addressed in a variety of ways through the years: How can developers get their code tested by enough users to make it acceptable in the main tree before it actually goes into the main tree?
The restrictions placed on projects going into staging are to make sure that all code preserves kernel stability and is moving in a direct line toward migrating out of staging and into its proper location in the official source tree. Therefore, any project going into staging should be well maintained, either by the person submitting it or by a volunteer who's willing to "babysit" the code. Staging is not a place to "dump code and run away," as Greg puts it. Any code that lives in staging will taint the kernel logs when executed (i.e., it'll print a message saying it ran code from staging).
Bug reports from a tainted kernel will be less likely to find folks willing to debug them. If you're working on code in staging, this puts most of the onus on you to debug it yourself, and if you think the bug wasn't triggered by your code, you should reproduce it on an untainted kernel and submit the report. Then, you'll find plenty of willing hackers to help you.
All of this is by way of isolating staging development from the rest of kernel development. As a developer of staging code, you benefit from an audience of potentially millions of users, but the responsibility of dealing with reports from those users, as well as the behavior of your own code, lies with you.
To me, this seems like a really elegant solution to a problem that has stymied kernel developers for years; no doubt it'll be improved as time goes by.
Version 16 of the popular Linux desktop reveals new tools, edge-snapping, and performance improvements.
Symantec says Linux-Darlioz burrows in through PHP.
Dell renews its quest for the ultimate developer machine.
Innovative back door looks like normal SSH traffic.
One of CeBITs most successful forums opens the new year with a new name. The popular Open Source Forum continues in 2014 under the name Special Conference: Open Source. This year, the forum will be bigger and offer a wider range of possibilities for sponsors.
New release offers better graphics drivers and expands filesystem support.
New mail protocol will shut out the NSA and prevent snooping on metadata.
A new web application helps users visualize distributed denial-of-service attacks.
Ubuntu 13.10 takes a step toward convergence, with lots of mobility, but Mir only partly here.
Galileo board is targeted to embedded developers and educational institutions.