Linux内核日常维护工作流程曝光,程序员拜读!
2021-03-19 10:28:48
58次阅读
0个评论

当Linux 5.8 Release Candidate最近开放测试时,最大的新闻不是它的内容,而是它的大小。正如Linus Torvalds本人指出的那样,……5.8似乎是我们有史以来最大的发行版之一。”

确实,RC 5.8具有超过14,000个非合并提交,约80万行新代码行,并增加了约100个新贡献者。由于COVID-19,很少有人去旅行了,所以它之所以变得如此之大,是因为我们所有人都能够在发布窗口中完成比平时更多的工作。但是从一个经验丰富的Linux内核贡献者和维护者的角度来看,5.8 RC发行版的空前规模对于那些正在维护它的人来说并不是问题。而软件项目的工作流程才是值得关注的的。

拥有最佳的工作流程意味着什么?对我而言,这归结为Linux内核开发人员随着时间的推移建立的一系列基本规则,以使他们能够持续不断地大规模,可靠地发展。以下是Linux内核工作流程的关键的七个最佳实践(或基本原则):


1.每次commit只能做一件事

Linux 的中心原则是,所有更改都必须分解为小步骤进行 —— 您的每个commit都只能做一件事。这并不意味着每个 commit 都必须很小,比如对在数千个文件中使用的函数的API进行简单更改,可以使更改量很大,但仍然可以接受,因为它是针对某一项单一任务的更改。通过始终遵循此原则,项目维护者可以更轻松地识别和隔离任何有问题的更改,而不影响其他的功能。

2.commit 不能破坏构建

不仅应该将所有更改分解为尽可能小的变量,而且还不能破坏内核。即每个步骤都必须完全起作用,并且不引起退化。这就是为什么对函数原型的更改还必须更新调用它的每个文件,以防止构建中断的原因。因此,每个步骤都必须作为一个独立的更改来工作,这将我们带到了下一点:

3.所有代码都是二等分的

如果在某个时候发现了错误,则需要知道是哪个更改导致了问题。从本质上讲,二等分是一种操作,它使开发者可以找到所有发生错误的确切时间点。

为此,请转到最后一个已知的工作 commit 所在的节点,并且已知第一个 commit 已损坏,然后在该点测试代码。如果可行,则前进到下一个节点;如果不是,则返回更上层的节点。这样一来,开发者就可以在十几次编译/测试中,从成千上万的可能 commit 中分离出导致问题出现的 commit 。Git 甚至可以通过 git bisect 功能帮助自动化该过程。

4.永远不要 rebase 公共分支

Linux 项目工作流程不允许 rebase 他人使用的任何公共分支。因为 rebase 这些公共分支后,已重新基准化的 commit 将不再与基于原存储库中的相同 commit 匹配。在树的层次结构中,不是叶子的公共主干部分不能重新设置基准,否则将会破坏层次结构中的下游分支。

5.Git 正确合并

其他的版本管理系统是合并来自不同分支代码的噩梦,它们通常难以弄清代码冲突,并且需要大量的手动工作来解决。而 Git 的结构可以轻松完成这项工作,因此 Linux 项目也从中直接受益。这就是为什么 5.8 版本的大小并不重要的重要原因。在 5.8-RC1 发布周期中,平均每天有 200个 commit ,并从 5.7 版本中继承了 880 个合并。一些维护者注意到了其中增加的工作量,但是对此仍然没有感到什么太大的压力或者导致倦怠。

6.保留定义明确的 commit 日志

不幸的是,这可能是许多其他项目忽略的最重要的原则之一。每个 commit 都必须是独立的,这也应该包括与该 commit 相应的日志。内核贡献者必须在更改的 commit 日志中做出说明,让所有人了解与正在进行的更改相关的所有内容。Rostedt 提到,他自己的一些最冗长和最具描述性的变更日志,往往是针对一些单行代码提交的,因为这些单行代码更改是非常细微的错误修复,且代码本身包含的信息极少。因此更改的代码越少,日志反而应该说明得更详细。

7.持续测试和集成

最后一项基本原则是开发过程中进行持续测试和持续集成。在向上游发送 commit 请求之前,开发者会测试每个 commit 。Linux 社区还有一个名为 Linux-next 的镜像 ,它提取维护人员在其存储库的特定分支上进行的所有更改,并对其进行测试以确保它们能正确集成。Linux-next 非常有效地运行着整个内核的可测试分支,该分支将用于下一个发行版。Linux-next 是一个公共仓库,任何人都可以测试它,这种情况经常发生 —— 人们现在甚至发布有关 Linux-next 中代码的错误报告。事实上,已经进入 Linux-next 几周的代码基本上可以确定会最终进入主线发行版中。

收藏 0 0

登录 后评论。没有帐号? 注册 一个。

xampp666

  • 0 回答
  • 0 粉丝
  • 0 关注