解决 Linux 内核代码审查人员短缺问题
时间:2016-10-31 16:45 来源:linux.it.net.cn 作者:IT
操作系统安全是现在最重要的事情,而 Linux 则是一个主要被讨论的部分。首先要解决的问题之一就是:我们如何确定提交到上游的补丁已经进行了代码审核?
Wolfram Sang 从 2008 年开始成为一名 Linux 内核开发者,他经常在各地召开的 Linux 峰会上发表讲话,比如在 2016 年柏林 Linux 峰会,他提出了如何提高内核开发实践的想法。
让我们来看看他的观点。
在 2013 年的时候,你曾在爱丁堡(Edinburgh)提醒 ELCE 委员会,如果不作出改变,那么子系统的潜在问题和其他争议问题将会逐渐扩大。他们做出改变了吗?你所提及的那些事件发生了吗?
是的,在某些程度上来说。当然了,Linux 内核是一个很多部分组成的项目,所以给以 Linux 各个子系统更多关注应该放在一个更重要的位置。然而,有太多的子系统“只是拼图中的一块”,所以通常来说,这些子系统的潜在问题还未被解决。
你曾指出代码审核人数是一个大问题。为何你觉得 Linux 内核开发社区没有足够的代码审核人员呢?
理由之一就是,大多数开发者实际上只是编写代码,而读代码并不多。这本是没有什么错,但却说明了并非每个人都是代码审核人员,所以我们真的应该鼓励每个人都进行代码审核。
我所看到另一件事就是,但我们要请人员加入我们的社区时,最重要的考核就是补丁贡献数量。我个人认为这是很正常的,并且在初期总贡献量少的时候是非常好的做法。但是随着越来越多的人员,特别是公司的加入,我们就碰到源码审核的问题。但是别误解了,有着数量可观的贡献是很棒的。但目前需要指出的是,参与社区有着更多内涵,比方说如何为下一步发展负责。有些部分在改善,但是还不够。
你认为更多的代码审核人员培训或者审核激励措施是否会有帮助?
我最主要的观点就是要指出,现今仍存在问题。是的,目前为止我们做到很好,但不意味着全都做的很好。我们也有类似扩张方面的问题。让人们了解事实,是希望能够让一些团体对此感兴趣并参与其中。尽管,我并不认为我们需要特殊的训练。我所熟悉的一些代码审核人员都非常棒或者很有天赋,只是这类人太少或者他们的空闲时间太少。
首先就是需要有这种内在动力,至于其它的,边做边学就非常好了。这又是我想要指出的优势之一:审核补丁能够使你成为更出色的代码开发者。
依你之见,是否有那么一个受欢迎的大项目在扩张这方面做的很好,可以供我们借鉴?
我还真不知道有这么一个项目,如果有的话随时借鉴。
我很专注于 Linux 内核,所以可能会存在一些偏见。然而在我看来,Linux 内核项目在规模大小、贡献数量和多样性方面真的很特别。所以当我想要找另一个项目来寻找灵感以便改善工作流是很正常的想法,目前我们的扩张问题真的比较特别。而且我发现,看看其他子系统在内核中做了什么是一个很有的方法。
你曾说安全问题是我们每个人都该想到的事情,那用户应该做些什么来避免或者改善安全问题的危险?
在今年(2016年)柏林 Linux 峰会我的谈话是针对开发层面的。安全隐患可能来自于没有正确审核的补丁中。我并不想要用户亲自解决这种问题,我更希望这些安全问题永远不会出现。当然这是不可能的,但这仍然是我处理问题所首选的方法。
我很好奇这个庞大社区如何改善这些问题。是否有你希望用户定期以文件形式提交的某些类型的错误报告?需要定期检查的区域却因为某些原因没有注意到的?
我们并不缺少错误报告。我所担心的是:由于代码审核人员的短缺造成补丁不完整,从而导致更多的错误报告。所以,到时候不仅需要处理大量的贡献,还需要处理更多错误或者进行版本回退。
你是否还有什么事情希望我们读者知道,以了解你所在的努力?
Linux 内核的特殊性,常常让我牢记着,在底层它就是代码而已。
(责任编辑:IT)
操作系统安全是现在最重要的事情,而 Linux 则是一个主要被讨论的部分。首先要解决的问题之一就是:我们如何确定提交到上游的补丁已经进行了代码审核? Wolfram Sang 从 2008 年开始成为一名 Linux 内核开发者,他经常在各地召开的 Linux 峰会上发表讲话,比如在 2016 年柏林 Linux 峰会,他提出了如何提高内核开发实践的想法。 让我们来看看他的观点。
在 2013 年的时候,你曾在爱丁堡(Edinburgh)提醒 ELCE 委员会,如果不作出改变,那么子系统的潜在问题和其他争议问题将会逐渐扩大。他们做出改变了吗?你所提及的那些事件发生了吗? 是的,在某些程度上来说。当然了,Linux 内核是一个很多部分组成的项目,所以给以 Linux 各个子系统更多关注应该放在一个更重要的位置。然而,有太多的子系统“只是拼图中的一块”,所以通常来说,这些子系统的潜在问题还未被解决。 你曾指出代码审核人数是一个大问题。为何你觉得 Linux 内核开发社区没有足够的代码审核人员呢? 理由之一就是,大多数开发者实际上只是编写代码,而读代码并不多。这本是没有什么错,但却说明了并非每个人都是代码审核人员,所以我们真的应该鼓励每个人都进行代码审核。 我所看到另一件事就是,但我们要请人员加入我们的社区时,最重要的考核就是补丁贡献数量。我个人认为这是很正常的,并且在初期总贡献量少的时候是非常好的做法。但是随着越来越多的人员,特别是公司的加入,我们就碰到源码审核的问题。但是别误解了,有着数量可观的贡献是很棒的。但目前需要指出的是,参与社区有着更多内涵,比方说如何为下一步发展负责。有些部分在改善,但是还不够。 你认为更多的代码审核人员培训或者审核激励措施是否会有帮助? 我最主要的观点就是要指出,现今仍存在问题。是的,目前为止我们做到很好,但不意味着全都做的很好。我们也有类似扩张方面的问题。让人们了解事实,是希望能够让一些团体对此感兴趣并参与其中。尽管,我并不认为我们需要特殊的训练。我所熟悉的一些代码审核人员都非常棒或者很有天赋,只是这类人太少或者他们的空闲时间太少。 首先就是需要有这种内在动力,至于其它的,边做边学就非常好了。这又是我想要指出的优势之一:审核补丁能够使你成为更出色的代码开发者。 依你之见,是否有那么一个受欢迎的大项目在扩张这方面做的很好,可以供我们借鉴? 我还真不知道有这么一个项目,如果有的话随时借鉴。 我很专注于 Linux 内核,所以可能会存在一些偏见。然而在我看来,Linux 内核项目在规模大小、贡献数量和多样性方面真的很特别。所以当我想要找另一个项目来寻找灵感以便改善工作流是很正常的想法,目前我们的扩张问题真的比较特别。而且我发现,看看其他子系统在内核中做了什么是一个很有的方法。 你曾说安全问题是我们每个人都该想到的事情,那用户应该做些什么来避免或者改善安全问题的危险? 在今年(2016年)柏林 Linux 峰会我的谈话是针对开发层面的。安全隐患可能来自于没有正确审核的补丁中。我并不想要用户亲自解决这种问题,我更希望这些安全问题永远不会出现。当然这是不可能的,但这仍然是我处理问题所首选的方法。 我很好奇这个庞大社区如何改善这些问题。是否有你希望用户定期以文件形式提交的某些类型的错误报告?需要定期检查的区域却因为某些原因没有注意到的? 我们并不缺少错误报告。我所担心的是:由于代码审核人员的短缺造成补丁不完整,从而导致更多的错误报告。所以,到时候不仅需要处理大量的贡献,还需要处理更多错误或者进行版本回退。 你是否还有什么事情希望我们读者知道,以了解你所在的努力?
Linux 内核的特殊性,常常让我牢记着,在底层它就是代码而已。 |