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
MSBuild is now just another GitHub project as Redmond continues its path to the light.
Malware could pass data and commands between disconnected computers without leaving a trace on the network.
New rules emphasize collegiality in coding.
Upstart lands in the dust bin as a new era begins for Linux.
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?
.NET Core execution engine is the basis for cross-platform .NET implementations.
The Xnote trojan hides itself on the target system and will launch a variety of attacks on command.
Spammers go low-volume, and 90% of IE browsers are unpatched.
Adobe scrambles to release patches for vulnerable Flash Player.