Linux内核开发者讲述他们关于Linux开发模式的共同困扰

为什么80%的码农都做不了架构师？>>>

每一个释放出的Linux内核，都有超过一千名开发者贡献的代码。这一过程，从技术角度上讲行之有效；但同时，它又有着同样大的弊病。

本周Linux基金会合作峰会中的一个座谈会中，数名顶级Linux内核开发者详细描述了他们关于Linux开发模式的共同困扰。 这不是一个适合（the feint of heart）的模式。

Linux创始人Linus Torvalds 本周在博客中写道，“公然取笑别人是开源编程快乐的一半。”他还说，“摆脱封闭编程的真正原因是，（那样的环境中）你无法公然难为别人。” （有点不解——译者注）

Linux内核开发者Greg Kroah-Hartman 向Linux基金会合作听众表示，他同意Torvalds的看法。

“确实我们偶尔取笑别人；但真正使我恼火的是，看到同样的问题一而再再而三地出现，”Kroah-Hartman 说。

Linux内核开发者Keith Packard 表示，他最大的困扰是看到补丁破坏现有的Linux功能。Packard 解释说，他最近发现Linux蓝牙功能有问题，发现是近期补丁中的一个退化破坏了现有的功能。于是他向蓝牙维护者发送了修复该问题的请求。他收复了回复， 对方告诉他，需要他更新自己的用户空间（userspace）！

“我最根本的困扰是，总有人不想想怎样能保留现有用户空间API，就随便发布补丁，”Packard 说，“我从来不喜欢那样的补丁，因此千万别提交改变用户空间API的补丁。”

变更记录是另一个为Linux内核开发者所头疼的问题。变更记录的目的是标定指定代码段中的发生的变更。Linux内核开发者James Bottomley 表示，他最不满意的是没有真正表述什么被改变了的变更记录。

“我收到了许多用做这做那来描述变更，但却未表明为什么这么做的变更记录，”Bottomley 说，“我想知道该变更所带来的对用户可见的效果是什么。”

按Bottomley 的观点，一个好的变更记录不应该描述变更本身，这是C代码做的事；它应该从用户可见的角度描述该变化，以及为什么应该有这一变化。

Red Hat Linux内核维护者John Linville 表示，他所面临的一个挑战是，提交的补丁是作为漏洞修复还是新特性，越来越缺乏明晰的界线。

“维护者也和大家每个人一样，没有那么的天才。因此，你需要告诉我们你真正指的是什么，”Linville 说。

Mel Gorman，一个SUSE Linux内核开发者，评论道他最大的困扰是，开发者不止一次地犯同类的错误。Gorman 补充道，他正在构建工具和一些数据，以帮助更加简单地定义一些常见易犯的问题。

“我想我们真的有必要，经得信时间的考验，竭力跟上这些细节，并保证我们正确地理解了它们。”Gorman说。


转载请注明：Linux人社区> 英文资讯翻译专版.编译

英文原文：
Linux kernel developers detail top gripes
posted by fran on Thu 5th Apr 2012 20:41 UTC
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.   

转载于:https://my.oschina.net/xyxzfj/blog/52496