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.
Buy this article as PDF
Should you trust an online service to store your online passwords?
New B+ board lets you build cool things without the complication of a powered USB hub.
Redmond rushes in to root out alleged malware haven.
New initiative will bring futuristic virtual reality effects to the web surfing experience.
Dyreza malware launches a man-in-the-middle attack that compromises SSL.
New cloud combines worldwide access with local attention to data security.
A first cousin of the recent Heartbleed attack affects EAP-based wireless and peer-to-peer authentication.
FOSS community acts to protect freedom of choice for laptop devices.
Quintessential open source browser shores up its market share with a step toward the proprietary dark side.
Authorities in 16 countries take action against users of the imfamous BlackShades malware tool.