Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Over a thousand developers contribute code to any given Linux kernel release. It’s a process that works well from a technical perspective, but it’s also one that has its fair share of shortcomings.
In a panel at the Linux Foundation Collaboration summit this week, top Linux kernel developers detailed their common pet peeves about the Linux development model. It’s a model that is not for the feint of heart.
Linux founder Linus Torvalds this week wrote in posting that, “publicly making fun of people is half the fun of open source programming.” He also noted that, “the real reason to eschew programming in closed environments is that you can’t embarrass people in public.”
Linux kernel developer Greg Kroah-Hartman told the Linux Foundation Collaboration audience that he agrees with Torvalds.
“It’s true sometimes we get to make fun of stuff but what makes me grumpy is seeing the same problems and patterns over and over,” Kroah-Hartman said.
Linux kernel developer, Keith Packard noted that his key pet peeve is seeing patches that break existing Linux functionality. Packard explained that he recently had some trouble with Linux Bluetooth functionality and noticed that there was a regression in a recent patch that broke existing functionality.So he sent a request to the Bluetooth maintainer to fix the issue. He received a response back, telling him he needed to update his userspace
“My basic pet peeve are people that submit patches that can’t think of a way to do it (the patch) without preserving the existing userspace API,” Packard said. “I never want to see a patch like that, so don’t submit a patch that changes the userspace API.”
Changelogs are another pet peeve cited by kernel developers. The purpose of a changelog is to identify what has been changed in a given piece of code. Linux kernel developer James Bottomley noted that his biggest pet peeve are changelogs that don’t actually tell you what has been changed.
“I get a lot of changelogs that describe the change as doing this and that, but they don’t tell you why they are doing it,” Bottomley said. “I want to know what the user visible effect of the change is.”
In Bottomley’s view, a well written changelog shouldn’t describe the change, since that’s what the c-code does. It should describe the user visible effects of the change and why it is being applied.
Red Hat Linux kernel developer John Linville noted that a challenge he faces is lack of clarity about whether submitted patches are intended as a fix or as a new feature.
“Maintainers are just as dumb as everybody else, so sometimes you need to tell us what you really mean,” Linville said.
Mel Gorman, a Linux kernel developer at SUSE, commented that his biggest pet peeve is when developers make the same class of mistake more than once. Gorman added that he’s now building tools and some data to help make it easier to identify some of those common mistakes.
“I think we really need to push much harder to keep track over time, of the simple stuff and making sure we keep it right,” Gorman said.
Sean Michael Kerner is a senior editor at InternetNews.com, the news service of the IT Business Edge Network, the network for technology professionals Follow him on Twitter @TechJournalist.
