如何看待华为称其对 Linux 贡献全球第一，Linux 内核审核员呼吁华为公司不要刷 KPI ?

其实这个问题和华为没关系

其核心在于让被迫996的程序员去搞开源

而且开源的提交量还要涉及到业绩，那么换了哪家公司的程序员也多半都是这个结果。

讨论问题的一个基本常识是，你可以质疑对方的行为，但是请不要随便质疑对方的动机。因为行为是一个事实，是比较容易证实的，而人的动机基本上是没法举证的。一旦你去质疑对方的动机，就会陷入一团麻花，除了浪费人的情绪之外没有任何意义。

就这个事件而言，如果Qu同学你认为对方的patch没有价值，你完全可以评论这东西为什么没价值，然后大家对它到底有没有价值展开讨论。但是你一上来就评论对方是为了刷KPI，试问你怎么知道对方是为了刷KPI，你怎么举证？对方完全可以说我就是完美主义，就是看这一丁点小问题不爽，必欲改之而后快。再说我都能投入时间去写patch，你为啥不能review patch呢？你不想review可以不review啊，是不是又因为review patch算你的KPI呢？……这样一来二去，这个问题就没法扯清楚了，因为谁都没法证实对方的动机。

另外，Qu所说的“already broken reputation”等用语就更令人反感了，这已经不是讨论客观事实，而是形同辱骂了。

Qu同学的代码能力我不清楚，但从这件事上来看，我觉得他显然缺乏处理争议的基本逻辑能力。在此我呼吁他还是不要为Linux社区review code了，免得拉低了Linux的质量水准……

先说我的结论，这事可以说不是刷 KPI ，但也可以说是。

为什么得出一个矛盾的结论？这条回答给出了一个解释：

因为之前华为被诟病代码质量差，从2019年开始，内部开始重视代码的质量。代码的规范化成了代码可信改进的一部分，所有不符合华为内部规范要求的代码都后在内部修改后提交上游。这就包括了拼写错误，以及 msg 信息这些“不重要”的内容，这也的确是 KPI 的一部分。但是目前没有证据证明华为内部有将 commit 数量作为 KPI 考核的依据。所以说，是，也不是。

这事引起争议主要原因不是 Qu Wenruo 针对某一条 commit 上岗上线，借机把华为批判一番，好弄个大新闻。在这之前，Leizhen 同一天发了6条 commit ，都是修改单词拼写。而更早的140+的 commit 相当部分也是这样的水 commit ，改一个单词，改一处 msg ，就发一个 commit 。review 队列都被这样的 commit 淹没了，以至于更重要的 fix 都挤到后面去了。这些 commit 明明至少浓缩到1/10，他们却发了一堆过来，被评审人拒绝还狡辩非要合并这些 fix，这完全有刷 KPI 嫌疑。这事换谁都火大。Qu Wenruo 们其实是忍了很久了，忍不住了就很不客气的公开抱怨出来了。

这些 fix 并不是说不可以，但是完全可以基本修改到位后一次性发个大补丁，这是对社区维护者的尊重。

担心有人没看完就发表评论，特地把重要的话加粗。。。。。。

本来我不想挂人的，但是来自某央企的大官某蓝先生一直在对 Qu 的身份冷嘈热讽。

您好大的官威啊，也不知道你那产品经理是个处级还是局级，还要求别人说话要符合自己的职级？这里自由软件社区，不是你那个一堆官僚的央企。在自由软件社区，即使普通贡献者也有批评的资格。

linux 这样的项目并不是某个企业内部的项目，而是无数企业合作开发的一个大型项目，它复杂程度已经大到任何一个 Maintainer ，包括 linus 在内都无法做到全面掌控。这种情况下来自不同行业和公司 Reviewer 就是非常重要的存在了。Reviewer 的责任至少包括以下内容：

1. 验证 commit 是否能真能解决问题；
2. 核实 commit 是否和其他部分（主要是 Reviewer 自己负责开发的部分）冲突；
3. 测试 commit 是否会引入新的 bug；

能做到这些的开发者绝不会是某蓝先生口中的普通开发者，而是有多年工作经验的老司机！而这些 Reviewer 通常都是与代码提交者不同企业的同行，而且可能还不止一个。所以我说这个类似于论文的同行评议不是乱说，而且这个比论文的同行评议的更严格。因为论文出了问题大不了撤回，代码代码审核不充分一旦发布出去就可能会造成无法预计的损失。kernel 5.10 发布后出现了 btrfs 性能严重倒退的 bug 就是由于代码审核不完整造成的，这正是一个内核开发者担忧的事情：

我们并不缺少错误报告。我所担心的是：由于代码审核人员的短缺造成补丁不完整，从而导致更多的错误报告。所以，到时候不仅需要处理大量的贡献，还需要处理更多错误或者进行版本回退。

—— 解决 Linux 内核代码审查人员短缺问题-阿里云开发者社区

这如引用的这篇文章提到的，Reviewer 完成是志愿行为，没有因此带来任何收入，而且审查代码是很花时间的，这些完全是“用爱发电”的 Reviewer 应该得到尊重。在本来 Reviewer 就缺少的情况的，还遇到一个用 commit 来灌水的人，这种浪费大家时间的行为严重影响到 linux 的开发质量，这种行为有什么好洗的？

不要以为是华为的就说不得！

其实有华为内部人指出，提交是通过bot脚本查出来的

并不是刷KPI

大概算灌水式刷提交量，bot伪装活人多次提交

用bot也就算了，还不一次全改完，就好像是为了看上去不像bot，非要漏一点改第二三次，多次提交，这么刷提交量确实有点……

反对的就是这么个行为，好几个文件都是同样的修改，用处也不大，就愣是这里改了那里漏一点，要多次提交，你说可不可以这么做吧，确实可以

可Reviewer要多花时间，approver也要多花时间，也是无端增加了别人的工作量

现在双方已和平解决，没必要对这个事件进行深究

为了打破西方在Linux上的话语权，为了防止访问Github触犯相关法律，为了捍卫刷KPI的权利。

建议以华为等国内厂商重用码云（http://gitee.com），在码云上维护中国版的Linux, 这样刷起KPI就不会有外国人指指点点了。

外国开发者，连同Github, 因为他们的傲慢与无知，正在搬起石头砸自己的脚。

更新

其实他们很好，不要过分解读

看他的修改，我觉得留着日志感觉更好，有问题了方便排查

       From: Zhen Lei <thunder.leizhen@huawei.com> To: Kees Cook <keescook@chromium.org>,  Anton Vorontsov <anton@enomsg.org>,  Colin Cross <ccross@android.com>, Tony Luck <tony.luck@intel.com>,  linux-kernel <linux-kernel@vger.kernel.org> Cc: Zhen Lei <thunder.leizhen@huawei.com> Subject: [PATCH 1/1] pstore: remove unnecessary oom message Date: Thu, 17 Jun 2021 17:10:54 +0800 Message-ID: <20210617091054.1547-1-thunder.leizhen@huawei.com> (raw)  Fixes scripts/checkpatch.pl warning: WARNING: Possible unnecessary 'out of memory' message  Remove it can help us save a bit of memory.  Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> ---  fs/pstore/platform.c |  4 +---  fs/pstore/ram_core.c | 15 ++++-----------  2 files changed, 5 insertions(+), 14 deletions(-)  diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c index b9614db48b1d..752c2338af6c 100644 --- a/fs/pstore/platform.c +++ b/fs/pstore/platform.c @@ -752,10 +752,8 @@ void pstore_get_backend_records(struct pstore_info *psi,    int rc;      record = kzalloc(sizeof(*record), GFP_KERNEL); -  if (!record) { -   pr_err("out of memory creating record
"); +  if (!record)     break; -  }    pstore_record_init(record, psi);      record->size = psi->read(record); diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c index fe5305028c6e..7da890505025 100644 --- a/fs/pstore/ram_core.c +++ b/fs/pstore/ram_core.c @@ -301,10 +301,8 @@ void persistent_ram_save_old(struct persistent_ram_zone *prz)   if (!prz->old_log) {    persistent_ram_ecc_old(prz);    prz->old_log = kmalloc(size, GFP_KERNEL); - } - if (!prz->old_log) { -  pr_err("failed to allocate buffer
"); -  return; +  if (!prz->old_log) +   return;   }     prz->old_log_size = size; @@ -429,11 +427,8 @@ static void *persistent_ram_vmap(phys_addr_t start, size_t size,   }     pages = kmalloc_array(page_count, sizeof(struct page *), GFP_KERNEL); - if (!pages) { -  pr_err("%s: Failed to allocate array for %u pages
", -         __func__, page_count); + if (!pages)    return NULL; - }     for (i = 0; i < page_count; i++) {    phys_addr_t addr = page_start + i * PAGE_SIZE; @@ -578,10 +573,8 @@ struct persistent_ram_zone *persistent_ram_new(phys_addr_t start, size_t size,   int ret = -ENOMEM;     prz = kzalloc(sizeof(struct persistent_ram_zone), GFP_KERNEL); - if (!prz) { -  pr_err("failed to allocate persistent ram zone
"); + if (!prz)    goto err; - }     /* Initialize general buffer state. */   raw_spin_lock_init(&prz->buffer_lock); --  2.25.1      

====

国外的同学明显没有感受到KPI对员工的重要。

没有KPI，那么年终奖就会很低，娃要吃饭喝奶，房子要还贷，作为一个赚钱的机器，多赚钱没有错，这个事情不只是在华为，如果在其他企业，我觉得也会存在，给Linux内核提交patch，那么在KPI上显得多么优雅。

当然，作为内核维护者，他们是痛苦的，他们每天面对很多很多的邮件，要处理很多很多的问题，不能因为你的KPI问题，就没有质量的提交代码，这样对我是不尊重的。

其他的没啥问题，他们都是在自己的角度处理事情。

比较尴尬的是，这个是华为的人暴雷的，毕竟他是华为，这样容易让别人知道我们的实际情况。

碰到菊花厂的问题就一群人互相撕咬。我觉得这不正常。要么是菊花厂自己有问题。要么是广大群众有问题。反正肯定是有问题。

纸糊为啥那么多人反感菊花厂？我想就是菊花厂搞的996、奋斗者协议、末位淘汰这些违反劳动法的玩意，深深的伤害了纸糊广大IT劳动者的切身利益。而另外一批纸糊用户就是学生，没出校门，天天挺菊花厂的，天天虽远必诛的，天天和这些IT劳动者互相怼。这是哪里都看不到的奇景。

我说什么好呢？天道好轮回！