華為開發(fā)者刷KPI？當(dāng)事人回應(yīng)了
近日，Linux 內(nèi)核維護者 Qu Wenruo 在一封郵件中指出華為的開發(fā)者 Leizhen 等人提交了大量補丁，有刷 KPI 嫌疑。這些提交的補丁主要用于“清理錯誤信息”和“修復(fù)拼寫錯誤”。
為了 KPI，華為員工也是拼了。Linux 內(nèi)核維護者的一封郵件爆出，華為開發(fā)者們提交大量補丁，是為了“刷 KPI”!
近日，Linux 內(nèi)核郵件列表出現(xiàn)了一封特殊的郵件，名為 Please don't waste maintainers' time on your KPI grabbing patches，目前已登頂 LKML 熱榜第一!
成功擠下了 Linux 祖師爺 Linus Torvalds 教訓(xùn)濫用 LKML 的消息。
郵件中，Linux 內(nèi)核維護者 Qu Wenruo 指出來自華為的開發(fā)者 Leizhen 等人所提交的補丁只是清理一些錯誤信息，或者修復(fù)拼寫錯誤，有刷 KPI 的嫌疑。
Qu 表示，如果這些補丁只是內(nèi)核新手或者學(xué)生提交的，他不會說什么。但這些提交來自 @huawei.com，而且不止一次。
他指責(zé)這些提交者刷 KPI，還大言不慚地狡辯，想要合并這些補丁，這實實在在地損害了公司聲譽。
Qu 希望這些人能夠停止刷 KPI，為 Linux 內(nèi)核的修復(fù)做一些真正有價值的貢獻。
Linux Kernel 5.10 貢獻，華為居首!
6 月 2 日，鴻蒙 OS 2.0 版本正式發(fā)布。
要知道，鴻蒙系統(tǒng)是基于 Linux 應(yīng)用程序接口實現(xiàn)內(nèi)核與硬件交互。
而在 Linux 內(nèi)核 5.10 版本中，華為內(nèi)核代碼貢獻排名第一!
其中，華為共提交的補丁數(shù)量為 1434 個，占比 8.9%。代碼修改 41049 行，占比 5.3%，代碼修改行排名第 2。
自動內(nèi)核缺陷發(fā)現(xiàn)機器人 HULK Robot 在內(nèi)核 Bug 發(fā)現(xiàn)榜單上排名第 2，發(fā)現(xiàn)了 15% 的內(nèi)核 Bug。
這些貢獻具體在 ARM64 架構(gòu)、ACPI 子系統(tǒng)、文件系統(tǒng)、海思芯片支持和代碼重構(gòu)方面都有體現(xiàn)，作為 Linux 的開發(fā)者和使用者，華為使用代碼的同時也在豐富并修改之前錯誤代碼內(nèi)容。
華為自 2012 年以來向 Linux 內(nèi)核社區(qū)貢獻第一個補丁以來，8 年來不斷增加對 Linux 社區(qū)的投入，從 1 個補丁 1 個開發(fā)者參與到 1434 個補丁 95 個開發(fā)者參與，從 0 個 Maintainer 到 26 個 Maintainer。
除了代碼日常維護，Bug 修復(fù)外，華為在代碼貢獻上未來將在 Linux 服務(wù)器操作系統(tǒng)領(lǐng)域中發(fā)現(xiàn)的新特性貢獻給 Linux 內(nèi)核社區(qū)。
網(wǎng)友：碼農(nóng)的“潔癖”
對于“刷 KPI”這件事，貢獻者本人也對此作出了回應(yīng)：
我過去對內(nèi)核的貢獻主要是對 ARM 64 SMMU 驅(qū)動程序的性能進行優(yōu)化，包括 iova 優(yōu)化、嚴(yán)格模式優(yōu)化和懶人模式優(yōu)化。同時也在致力于開發(fā)部分 ARM SoC 驅(qū)動程序。
知乎一位工程師的高贊回答中，大概在 2017 年及以前，這個人的 patch 雖然不多，但大部分還是有意義的 patch。
2018 年底到 2020 年下半年幾乎銷聲匿跡快兩年，然后一年前突然又出現(xiàn)，出現(xiàn)后畫風(fēng)慢慢的就不太對了，像是找到了什么“法門”，patch 數(shù)量漸漸多了起來。
但是“風(fēng)格”逐漸向“看著改了很多，但是大部分又沒大用”的方向發(fā)展下去了，和之前的 patch 平均質(zhì)量比可以說是下降了幾個臺階。
這位工程師后續(xù)補充道：我還是希望大家能以平常心看待這個事情，截至目前 3 天過去了，事發(fā)地(Linux 郵件列表)里都沒有什么人爭論這個事，就當(dāng)事人回復(fù)了一下那個警告而已。
有網(wǎng)友表示，其實很多程序員也有“潔癖”，看到格式不舒服的代碼都想去調(diào)整一下。
從 Linux 內(nèi)核維護者 Qu 的角度來說，把拼寫錯誤等簡單問題當(dāng)做新手村留給新人，有經(jīng)驗的開發(fā)者致力于解決更深一層問題。這種出發(fā)點是沒錯的。
但是站在開發(fā)者的角度也沒錯。提交 Bug 本來就是開發(fā)者應(yīng)該做的，無論 Bug 大小，如果新手一天不清理拼寫錯誤，難道就把拼寫錯誤放在那里?
從這個角度來說，內(nèi)核維護者是不是應(yīng)該反思，為什么小 Bug 一直沒清理，反而等到華為開發(fā)者清理了，卻被認為是搶貢獻度。
郵件全文：
嗨，Leizhen，還有郵件列表里的人。
最近我發(fā)現(xiàn)一個補丁從 btrfs selftest 中刪除了一個調(diào)試 OOM 的錯誤信息。
這不是什么特別的東西，是一些內(nèi)核新手的小清理工作。
但是補丁提交人的郵件地址讓我很謹(jǐn)慎，「@huawei.com」。
上一次，我們從同一家公司得到了一些類似的補丁，他們在做一些無害的 「清理」工作，「清理」行為是無害的，但這些「修復(fù)」也是無用的。
這讓我懷疑，這里到底發(fā)生了什么。
經(jīng)過一些搜索，越來越多的 OOM 錯誤信息 「清理」補丁出現(xiàn)了。甚至還有一些修復(fù)拼寫錯誤的補丁。
新手/學(xué)生開發(fā)者提交這樣的補丁是可以的，而且希望這樣的補丁能讓他們成為一個長期的貢獻者。
事實上，我也正是通過做這樣的 「清理」開始我的內(nèi)核貢獻的。
但你們的做法實在是在刷 KPI，我已經(jīng)看到了。
并且我留意到好幾個維護者在和你爭論這種 「清理」，而你卻在為自己辯護，試圖讓這些補丁被合并。
你發(fā)送的補丁代表了你的公司，這樣做其實只是破壞了已經(jīng)破碎的聲譽。
請停止這種搶奪 KPI 的行為，并修復(fù)受損的聲譽。
謝謝。
Qu
來源：轉(zhuǎn)載自公眾號新智元(ID：AI_era)
