Linux內核開發者講述他們關於Linux開發模式的共同困擾

每個釋放出的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.