没错，一直以来，一切都保持不变。即，代码被发送到一个邮件列表（或多个列表），并在那里进行审查和讨论，直到被认为可以包含在Linux内核中为止。 但是，尽管事实上，这种使用代码的过程已经成功使用了很多年，但它一直受到批评。例如这个
微软的萨拉·诺沃特尼（Sara Novotny）最近发表的一篇文章在互联网上引起了轩然大波。那篇文章说，用于开发Linux内核的代码协作技术已经过时。它说，如果Linux开发人员社区希望吸引年轻的专业人员加入他们的行列，那么用更现代的方法代替这些方法将是不错的选择。在围绕这些想法的辩论中，他们的捍卫者和反对者发生了冲突。
我相信我的职位可以让我提供有关Linux内核开发的一些想法。近十年来，我一直在为Linux和以类似方式组织的其他项目编写代码。在Red Hat期间，我为x86内核基础结构代码，KVM虚拟机管理程序和QEMU仿真器代码以及Xen虚拟机管理程序代码做出了贡献。我也参与了其他项目的开发。我没有约7年，但只是由于这样的事实，我投入我的时间对C ++的工作做太多的Linux海星框架和ScyllaDB数据库...这两个项目都是使用与Linux开发中非常相似的方法开发的。我现在在Datadog担任首席工程师，该公司的软件开发过程与Linux中使用的过程几乎完全相反。这与其他Web公司中的开发组织方式非常接近。
那我在哪一边？让我马上说清楚，我不喜欢Linux开发过程。我很确定这不仅是新开发人员的障碍，还是代码高生产率的障碍（而且这与使用电子邮件完全无关）。这是开发人员所经历的负面情绪的来源。而且我不会在任何项目中都遵循该模型，因为我有权在该项目中就如何组织工作做出决策。
但是同时，似乎许多批评Linux开发过程的人认为，Linux捍卫者为之奋斗的事实仅仅是Linux社区中充斥着对传统和不愿意以任何借口改变。事实并非如此（尽管我确定Linux社区中有这样的人）。 Linux内核开发过程为其用户带来了一些独特而重要的好处。如果将相同的原理应用于任何其他项目，则此类项目将仅从中受益。
除电子邮件外，任何其他工具都使使用它们的人死板，使Linux失去了这种优势。邮件列表只是一种引起辩论者注意的引人注目的机制。我们需要可以降低Linux开发人员进入门槛的工具。可以纠正开发过程中缺陷的工具。一种使不同组织能够认识Linux开发组织的优势的工具。诸如此类的工具确实可以对整个软件开发行业产生影响。
这些机制中有许多是非常有益的。为了不延长对话时间，我将重点介绍其中之一，我认为这是最重要的。我将尽我最大的努力来揭示它的本质，并讨论为什么它尽管具有优势，却在开发人员中引起了如此多的负面情绪。我还将告诉您，为什么它一方面可以使其他项目受益，另一方面-为什么它对Linux非常重要。
提交消息和补丁
在Linux内核开发世界中，有一条规则：打算包含在内核中的代码必须分成单独的补丁。他们每个人都只能解决一个问题。应该为每个补丁准备有意义的提交消息。通常，此类消息的长度超过其描述的代码。
这是其他项目通常缺乏的主要示例。我在GitHub上的现代项目中看到的大多数提交消息看起来都像是“截至8月25日的更改”，或者稍微好一点（但只有一点点），比如“函数X的实现”。如果将来有人需要看这样的代码，他们将不容易弄清楚为什么要对代码进行此类更改。这些提交修复的一些错误可能很微妙。如果您不知道这些错误的确切解决方法，则可以轻松地返回到项目。当我阅读简短的，毫无意义的提交消息时，我可能不知道在什么情况下发现了该错误。
这是一个小例子。看一下对Linux内核的提交由我的好朋友约翰·魏纳（Johann Weiner）制作。我很容易想象，在另一个项目中，发送给类似提交的消息看起来像是“删除警告”。当我阅读这里讨论的提交信息时，我会了解到为什么有可能在不损害项目的情况下摆脱这些警告，以及在什么情况下确实不会导致任何不良后果以及什么原因。如果有一天决定更改此代码，则必须遵守规则。
我确信许多组织中都有人这样做。但是，在使用Linux内核时，从事此业务的每个人都必须这样做。因此，我非常有信心，通过阅读提交消息，我将了解有关相应代码更改的所有知识。如果我们正在谈论一个错误，那么我将了解它在哪些系统中表现出来，在什么条件下发生，为什么它不会以任何方式影响其他系统以及应该注意什么才能使该错误不会返回到项目中。
这种工作在任何组织中都是非常需要的。这使其他人（以及开发人员本人，在一段时间后转向他的代码）更容易理解更改代码的原因，并理解为什么代码按其工作方式工作。这使新程序员更容易了解项目。这解决了返回旧错误的问题，减少了某些似乎与所讨论的代码无关的代码可能破坏其中某些代码的危险。
在其他项目中，这是“非常理想的”。但是在Linux中绝对有必要，原因有两个：
- Linux . , . Linux, , - . , , , . ( ) , Linux. , Linux.
- (). Linux, . , 2020 , Linux , LTS-. , , - , Linux LTS-, Linux. , 2000- , . , , Red Hat .
对于不需要维护多个并行产品线的现代在线公司来说，后向移植通常不是问题。他们创建一些东西，然后将其传递给用户，然后它就结束了。但是，当backport发挥作用时，事情就变得更加复杂。开发人员（可能不是程序的作者）可能需要决定如何略微修改代码以适应与现代代码库稍有不同的旧代码库。使风险最小化的解决方案通常是（并且经常是）一种解决方案，其中包括仅创建补丁以实施大量变更的特定部分。想象一下，其中包含5行代码的2,000行提交可以修复错误。另外，假设重构API后发生此错误。您会选择什么：基于大量更改或基于文档齐全，文档齐全，已分解的补丁程序来准备反向端口？作为一个无数次支持的人，我已经知道我将如何回答这样的问题。
好吧，无论有没有支持，项目都必须付出高昂的代价，因为在这样的情况下，如果组织者非常注重仔细地记录变更，那么这样做的好处就很大。现在，程序员不仅需要照顾代码，还要照顾如何重新组织代码并使之与项目的工作规则保持一致。
其中一些代码重构很简单。假设我们正在谈论使用git add -p命令，然后选择要在一批更改中使用的内容。如果程序员面对各个代码片段之间的循环依赖关系，事情会变得更加复杂。想象一个函数返回一个类型的对象，该对象将在添加到该项目后添加到项目中。为了应对这种情况，您将不得不使用代码，因此，代码不会进入完成的项目，而只会起到临时解决方案的作用。
所有这些使程序员感到头疼，但是不能说这样的任务是完全无法解决的。假设您已通过手术将您所做的所有事情都分成了易于使用的片段。真正的问题开始于其他程序员开始查看您的代码之后。任何组织中的代码审查都是非常重要的。专家阅读他人的代码并提出（或要求）对其进行更改。
假设要求程序员从一组修补程序中向第一个补丁中存在的特定方法添加新参数。并且还假设此方法在所有后续补丁中都使用。
这意味着程序员将不得不回到第一个补丁，并向该方法添加一个新参数。之后，将不再应用下一个补丁。因此，程序员不仅要困惑为什么会这样，而且还需要手动纠正所有错误。如果先前已测试所有单个补丁程序，那么现在这些测试的结果已过时，因此必须再次测试补丁程序。
重组工作是一个小问题。但是，对已经完成的工作进行返工是一个更为严重的问题。
这是我想传达给Linux开发人员社区以及与该社区相关的人员的内容：所有这些当然都是可行的。但是，如果这不是年轻专业人员的入门障碍，那么我什至不知道什么可以称为“入门障碍”。花费时间，精力，神经和计算机资源来进行重组，重写，重做已完成的工作的需求显然不是程序员所追求的。在这方面，我遇到了一个以这种形式定期出现的想法：“ ...但是一个好的程序员不会对此有问题。”也有人这样说：“但是它教会了程序员某种思维方式，恰恰是一个好的程序员应该拥有的那种思维方式。”这种推理对我来说似乎是虚伪的，不会带来任何好处。确实：我刚刚列出了此方法的所有优点，但是我也发现所有这些代码重构都是繁琐而繁琐的任务。可以比作打扫公寓。假设有人说保持房屋清洁非常好（我同意）。同一个人完全有能力为地板吸尘（我可以），但很多时候他没有。原因很简单：他还有其他更重要的事情要做。例如，这就是为什么我非常高兴拥有Roomba机器人吸尘器的原因。这东西让我享受清洁，同时又不让我自己整理东西。这使我想到了针对Linux世界之外的人们的下一个想法。所有这些代码重构都是繁琐而繁琐的任务。可以比作打扫公寓。假设有人说保持房屋清洁非常好（我同意）。同一个人完全有能力为地板吸尘（我可以），但很多时候他没有。原因很简单：他还有其他更重要的事情要做。例如，这就是为什么我非常高兴拥有Roomba机器人吸尘器的原因。这东西让我享受清洁，同时又不必整理自己。这使我想到了针对Linux世界之外的人们的下一个想法。所有这些代码重构都是繁琐而繁琐的任务。可以比作打扫公寓。假设有人说保持房屋清洁非常好（我同意）。同一个人完全有能力为地板吸尘（我可以），但很多时候他没有。原因很简单：他还有其他更重要的事情要做。例如，这就是为什么我非常高兴拥有Roomba机器人吸尘器的原因。这东西让我享受清洁，同时又不必整理自己。这使我想到了针对Linux世界之外的人们的下一个想法。同一个人完全有能力为地板吸尘（我可以），但很多时候他没有。原因很简单：他还有其他更重要的事情要做。例如，这就是为什么我非常高兴拥有Roomba机器人吸尘器的原因。这东西让我享受清洁，同时又不必整理自己。这使我想到了针对Linux世界之外的人们的下一个想法。同一个人完全有能力为地板吸尘（我可以），但很多时候他没有。原因很简单：他还有其他更重要的事情要做。例如，这就是为什么我非常高兴拥有Roomba机器人吸尘器的原因。这东西让我享受清洁，同时又不必整理自己。这使我想到了针对Linux世界之外的人们的下一个想法。针对Linux世界之外的人们。针对Linux世界之外的人们。
我想对Linux社区以外的人说：在Linux上使用的开发过程中有非常强大的力量。某种工具无法完全应付在Linux上工作的任务。例如，GitHub在那些总是在现有代码之后添加新代码的项目上做得很好。当然，您可以使用git push --force命令，强行在存储库中包括某个分支，但是实际上，提交的附加注释将“悬而未决”，并且对该提交的讨论将毫无意义。
现代开发工具简化了很多。它们使您可以在某些情况发生时触发某些操作的执行，它们支持持续的集成和项目部署过程，将代码中的更改通知程序员，并解决许多其他任务。但是，它们的确使将某人的工作结果分解为易于操作的小程序的过程变得复杂。纯文本电子邮件的使用使情况变得非常复杂，但是应该注意，这种工作安排不会干扰实现特定目标的开发过程的应用。
即使有可能通过放弃现有的开发过程来客观，准确地评估Linux生态系统将获得和失去多少（什么也不会损失），它几乎不会改变任何东西。事实是，当人们努力保存以前在实践中表现得很好的东西时，当前的情况完美地说明了人的本性。
有没有办法解决这种情况？
我真诚地相信，如果我们拥有可供使用的工具，这些工具可以为不同的组织提供Linux社区从其开发方法学中获得的相同收益，那么它对每个人都将非常有益。如果确实存在这样的工具，那么甚至Linux社区也可以用它们代替常规的文本电子邮件。
对于这些工具的外观，我没有任何答案。但是，我将允许我自己尝试一下，并反思一下：
- Git — . , , , , . GitHub, - git-, «-» Linux, git, . , -, , , , . Git . CSS HTML, — , CSS HTML- . , HTML CSS? , , , .
- , , , , , . , , , ? . , : « create_foo() , create_bar()», : « create_bar() y, ». , , . , , , , GPT-3, , .
- , , , , - , . , , , . , , , , , , , , , .
-, Linux?
