document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-25 23:11:02 +08:00
Code Issues Packages Projects Releases Wiki Activity

[完成翻译] Solving the Linux kernel code reviewer shortage

Browse Source 
解决 Linux 内核代码审查人员短缺问题
This commit is contained in:
GHLandy 2016-10-18 15:30:55 +00:00
parent 9eee0cb8d4
commit 72e2d2d883
2 changed files with 58 additions and 60 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
sources/tech/20161005 Solving the Linux kernel code reviewer shortage.md
View File

@ -1,60 +0,0 @@
GHLandy Translating
Solving the Linux kernel code reviewer shortage
====
Operating system security is [top of mind right now](http://www.infoworld.com/article/3124432/linux/is-the-linux-kernel-a-security-problem.html), and Linux is a big part of that discussion. One of the questions to be solved is: How do we ensure that patches going upstream are properly reviewed?
Wolfram Sang has been a Linux kernel developer since 2008, and frequently talks at Linux conferences around the world, like[LinuxCon Berlin 2016](https://linuxconcontainerconeurope2016.sched.org/event/7oA4/kernel-development-i-still-think-we-have-a-scaling-problem-wolfram-sang-consultant), about ways to improve kernel development practices. 
Let's get his point of view.
![](https://opensource.com/sites/default/files/images/life/Interview%20banner%20Q%26A.png)
### In 2013, you warned the ELCE audience in Edinburgh about subsystem latencies and other issues that may arise if things don't change. Did things change? Did some of the things you warned about end up happening?
Yes, to some extent. Of course, the Linux kernel is a very heterogeneous project, so subsystems with more focus are in a slightly better position. However, there are enough subsystems which are "just a piece of the puzzle" and for them latency has not improved, generally speaking.
### You've pointed out that the number of reviewers is a problem. Why do you think the kernel development community doesn't have enough reviewers?
One thing is that some people prefer to actually write code and not so much read code. This is OK. It just shows that not everyone is a reviewer, so we should really encourage everyone who likes to do that.
Another thing I see is when we ask people to join our community, it is first mostly about contributing patches. This is natural, I think, and worked well in the beginning when contributions were fewer. But as more and more have joined, especially companies, we've hit this review resource problem. Don't get me wrong, having so many contributions is awesome! I think that we now need to point out that taking part in the community also means more, like to take over some responsibility as a next step. It happens in some parts, but it is not enough to scale yet.
### Do you think more reviewer training or incentivization of reviewing would help?
One key point for me is to speak out about there being a problem. Yes, we are doing great so far, but that doesn't mean all is well. We also have problems like this scalability issue. Let people know so maybe some parties get interested and join. I don't think we need special training, though. Most reviewers I know are pretty good or talented, they are just too few or have too little time.
What you should have is this intrinsic motivation. For the rest, learning-by-doing works great in this field. This is one of the advantages I like to point out: Reviewing patches makes you a better coder.
### In your opinion, are there large, popular projects that you think are doing a really great job at scaling that we might borrow some ideas from?
I don't know one, but am open to hearing about them if there are.
I am very focused on the Linux kernel, so it might be plain bias. However, in my opinion the kernel is indeed special in terms of size, number of contributions, and diversity. So while I think looking at other projects to get inspiration for workflow improvements is always healthy, our scalability problems are pretty unique currently. I find it most useful to look what other subsystems in the kernel are doing.
### You've mentioned security issues as something that could come up. What should users be doing to avoid or ameliorate the severity of security issues?
My talk at LinuxCon Berlin this year is targeted at the development level. The security implications could come from patches going in without proper review. I don't want to have users deal with that, I rather want such issues to never happen. This will never work perfectly, but it is still my preferred way to tackle things.
### I'm wondering how the wider community could help. Are there certain kinds of bug reports that you wish people would file more often? Particular areas that need regular attention but don't get it for some reason?
We are not short on bug reports. What I am more afraid of is that the shortage of reviewers will lead to more bug reports due to incomplete patches going in. So, we then we'll not only have to deal with the huge amount of contributions, but also with more bugs and regressions.
### Is there anything else you wish our readers knew about your work?
With all the specialities around the Linux kernel, it often helps me to remember that at the bottom, it is just code.
--------------------------------------------------------------------------------
via: https://opensource.com/business/16/10/linux-kernel-review
作者：[Deb Nicholson][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/eximious

58
translated/tech/20161005 Solving the Linux kernel code reviewer shortage.md Normal file
View File

@ -0,0 +1,58 @@
解决 Linux 内核代码审查人员短缺问题
====
操作系统的安全性能是 [第一要务](http://www.infoworld.com/article/3124432/linux/is-the-linux-kernel-a-security-problem.html),而 Linux 则是该要务的一大组成部分。首先要解决的问题就是：我们如何确定提交到上游的补丁已经进行了代码审核？
Wolfram Sang 从 2008 年开始成为一名 Linux 内核开发者，他经常在各地召开的 Linux 峰会上发表讲话，比如在 [2016 年柏林 Linux 峰会](https://linuxconcontainerconeurope2016.sched.org/event/7oA4/kernel-development-i-still-think-we-have-a-scaling-problem-wolfram-sang-consultant)，他提出了如何提高内核开发实践的想法。
让我们来看看他的观点。
![](https://opensource.com/sites/default/files/images/life/Interview%20banner%20Q%26A.png)
### 在 2013 年的时候，你曾在爱丁堡（Edinburgh）提醒 ELCE 委员会，如果不作出改变，那么子系统的潜在问题和其他争议问题将会逐渐扩大。他们做出改变了吗？你所提及的那些事件发生了吗？
是的，在某些程度上来说。当然了，Linux 内核是一个很多部分组成的项目，所以给以 Linux 各个子系统更多关注应该放在一个更重要的位置。然而，有太多的子系统“只是一块拼图”，所以通常来说，这些子系统的潜在问题还未被解决。
### 你曾指出代码审核人数是一个大问题。为何你觉得 Linux 内核开发社区没有足够的代码审核人员呢？
理由之一就是，大多数开发者实际上只是编写代码，但没有再次去通读之前写的代码。这本是没有什么错，但却说明了并非每个人都是代码审核人员，所以我们挣得应该鼓励每个人都进行代码审核。
我所看到另一件事就是，但我们要请人员加入我们的社区时，最重要的考核就是补丁贡献数量。我个人认为这是很正常的，并且在初期总贡献量少的时候是非常好的做法。但是随着越来越多的人员，特别是大型公司的加入，我们就碰到源码审核的问题。但是别误解了，有着数量可观的贡献是很棒的。但目前需要指出的是，参与社区意味着更多，比方说如何为下一步发展负责。有些部分在慢慢改善，有一些部分现在则不宜扩张。
### 你认为跟多的代码审核人员或者审核激励措施是否会有帮助？
我最主要的观点就是要指出，现今仍存在问题。是的，目前为止我们还没有做到最好，但不意味着所以都没做好。关于这个可伸缩性争议，我们还存在其他的问题。让人民了解事实，是希望能够让一些团体对此感兴趣并参与区中。我并不认为我们需要特殊的训练，我所熟悉的一些代码审核人员都非常棒或者很有天赋，只是这类人太少或者他们的空闲时间太少。
首先就是需要有这种内在动力，至于这个另一种其他的，边做边学就非常好了。这又是我想要之处的优势之一：审核补丁能够使你成为更出色的代码开发者。
### 依你之见，是否与那么一个受欢迎的大项目在扩张这方面做的好又可以让我们借鉴的？
我还真不知道有这么一个项目，如果有的话随时借鉴。
我很专注于 Linux 内核，所以可能会存在一些偏见。然而在我看来，Linux 内核项目在规模大小、贡献数量和多样性方面真的很特别。所以当我想要找另一个项目来寻找灵感以便改善工作流是很正常的想法，目前我们的可伸缩性问题真的比较特别。而且我发现，跟踪请其他子系统在内核中做了什么是一个很有的方法。
### 你曾说安全问题是我们每个人都该想到的事情，那用户应该做些什么来避免或者改善安全问题的危险？
在今年（2016年）柏林 Linux 峰会我就说过，这是开发层面的问题，安全隐患可能存在于没有正确审核的补丁中。我并希望需要用户亲自解决这种问题，我更希望这些安全问题永远不会出现。当然这是不可能的，但这仍然是处理问题所喜欢用的方法。
### 我很好奇这个庞大社区如何改善这些问题。是否有某些类型的错误报告（bug report）用户定期以文件形式提交？需要定期检查的区域却因为某些原因没有注意到的？
我们并不缺少错误报告。我所担心的是：由于代码审核人员的短缺造成补丁不完整从而导致更多的错误报告。所以，到时候不仅需要处理大量的贡献，还需要处理更多错误或者进行版本回退。
### 你是否还有什么事情希望我们读者知道，以了解你所在的努力？
Linux 内核中所有的特殊项目常常让我牢记着最底层的事情，那就是代码。
--------------------------------------------------------------------------------
via: https://opensource.com/business/16/10/linux-kernel-review
作者：[Deb Nicholson][a]
译者：[GHLandy](https://github.com/GHLandy)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/eximious