linux内核代码_解决Linux内核代码审阅者短缺的问题

linux内核代码

目前，操作系统安全性是首要考虑因素，而Linux是该讨论的重要组成部分。要解决的问题之一是：我们如何确保正确审查上游的补丁程序？

Wolfram Sang自2008年以来一直是Linux内核开发人员，并经常在世界各地的Linux会议（如LinuxCon Berlin 2016 ）上讨论改善内核开发实践的方法。

让我们了解他的观点。

2013年，您警告爱丁堡的ELCE观众有关子系统延迟和其他情况的信息，如果情况没有改变，可能会出现其他问题。事情变了吗？您警告过的某些事情最终发生了吗？

是的，在某种程度上。当然，Linux内核是一个非常异构的项目，因此具有更多重点的子系统的位置会稍好一些。但是，有足够的子系统只是“难题的一部分”，从总体上来说，它们的等待时间并没有得到改善。

您已经指出，审阅人数众多是一个问题。您为什么认为内核开发社区没有足够的审稿人？

一件事是，有些人更喜欢实际编写代码，而不是阅读大量代码。还行吧。它只是表明并非每个人都是审稿人，因此我们应该真正鼓励每个喜欢这样做的人。

我看到的另一件事是，当我们要求人们加入我们的社区时，首先主要是贡献补丁。我认为这是很自然的，并且在捐款减少的一开始就很有效。但是随着越来越多的人加入，尤其是公司，我们遇到了这个评论资源问题。不要误会我的意思，做出这么多的贡献真是太棒了！我认为我们现在需要指出，加入社区也意味着更多，就像下一步要承担一些责任一样。它发生在某些部分，但还不足以扩展。

您认为更多的审稿人培训或激励审稿会有所帮助吗？

对我来说，一个关键点就是说出问题所在。是的，到目前为止我们做得很好，但这并不意味着一切都很好。我们也有类似此可伸缩性问题的问题。让人们知道，所以也许有些政党有兴趣加入。不过，我认为我们不需要特殊培训。我认识的大多数评论家都非常优秀或有才华，他们太少或时间太少。

您应该拥有的是这种内在动力。对于其他方面，边做边学在该领域非常有用。这是我要指出的优点之一：查看补丁可以使您成为更好的编码器。

在您看来，您是否认为有一些大型的，受欢迎的项目在扩展方面做得非常好，我们可能会借鉴一些想法？

我不认识，但是愿意听到关于它们的信息。

我非常关注Linux内核，因此可能是个偏见。但是，在我看来，内核在大小，贡献数和多样性方面确实确实很特殊。因此，尽管我认为寻找其他项目来获得工作流改进的灵感总是健康的，但目前我们的可伸缩性问题非常独特。我发现查看内核中的其他子系统正在做什么最有用。

您已经提到安全问题可能会出现。用户应该怎么做才能避免或减轻安全问题的严重性？

我今年在柏林LinuxCon上的演讲是针对开发水平的。安全隐患可能来自未经适当审查就打入的补丁。我不想让用户处理这些问题，而是希望此类问题永远不会发生。这将永远无法完美运行，但这仍然是我解决问题的首选方式。

我想知道更广泛的社区将如何提供帮助。您是否希望某些种类的错误报告使人们更频繁地提交？需要定期关注但由于某种原因而没有得到关注的特定领域？

我们的bug报告也不短。我更担心的是，由于缺少不完整的补丁程序，审阅者的短缺将导致更多的错误报告。因此，我们不仅要处理大量的工作，而且还要处理更多的错误和回归。

您还希望读者了解您的作品吗？

凭借围绕Linux内核的所有专业知识，它通常可以帮助我记住最底层的只是代码。

翻译自: https://opensource.com/business/16/10/linux-kernel-review

linux内核代码