LWN: Emacs讨论使用基于web的工作流程！
关注了就能看到更多这么棒的文章哦～
Emacs discusses web-based development workflows
By Jake Edge
September 1, 2021
DeepL assisted translation
https://lwn.net/Articles/867956/
过去几年里，关于如何使 Emacs 编辑器 "现代化(moderize)" 的讨论以多种形式出现过。在 Emacs 社区中，这种类型的改动往往是有争议的，更容易让那些重视现有功能（以及现有的按键绑定）的 "守旧派" 与那些主张改变 Emacs 让其对新人更容易上手（并且能更加美观）的人对立起来。这些讨论经常会引出长长的讨论，所以关于可能将 Emacs 开发转移到一些 "forge" 网站（如 GitHub 或 GitLab 之类）的提议毫不意外也出现了类似的情况。在 Emacs 领域，讨论总是会牵涉到许多方面，比如人们是否愿意摆脱基于电子邮件的工作流程、从而适应年轻的、熟悉 forge 网站的开发者们，但又不用强迫现有开发者们也采用这种新的工作模式，此外当然还有 licensing 问题。
作为 emacs-devel 邮件列表的新成员，Daniel Fleischer 可能没有想到他在 8 月 26 日的帖子会得到大量回应，他的文章里询问了 "迁移到新的 VC（版本控制）系统，例如 Gitlab "的进展。邮件的主题 "Gitlab Migration" 有些挑衅性，这也帮助吸引了不少眼球（和回应）。Dmitry Gutov 说，目前没有进行迁移的计划，而 GitLab 两年前关于这个话题的 feature request 就说明了需要进行 "相当艰巨的 "工作。Richard Stallman 则有不同的担忧：
我们曾经推荐过 GitLab，认为它比 GitHub 好（其实也只是勉强可以接受）。然而，GitLab 已经变得更糟了，我们应该完全停止推荐它。
他建议，从 licensing 和理念的角度来看，sourcehut 或 NotABug.org 可能更合适。除了 Emacs 的共同维护者 Eli Zaretskii 要求对 NotABug.org 进行评估外，在这个话题中没有听到多少关于这个开发托管网站的消息；另一方面，sourcehut 则多次出现。Stallman 说，任何解决方案都需要是基于 GNU 基础设施的，而不是仅仅需要一个托管服务；他还担心如果需要 JavaScript 的话是否有 free-software 版本。
在最初的帖子中，Fleischer 指出了他认为改用 forge 工具的两个好处。他说，因为年轻的开发者更熟悉 forge 式的工作流程，提供这一点将降低新开发者的入门门槛。此外，不用把项目的多个组成部分分散在多个系统中，使项目的工作更容易进行：
将代码+issue+讨论放在同一个地方，而不是像现在这样，代码和讨论（list）在三个不同的地方（Savannah、Gnu 邮件列表和 Gnu bug tracker）。有了更现代的 VC 系统的话，人们可以很容易地在 issue、讨论、代码提交之间来回跳转，而不是像现在这样，如果是一个 bug，你可以用它的编号来搜索列表和提交信息，但如果是讨论的话，就没有办法搜索到相关的 "关联" 内容了。
他还指出，应该仍然支持基于电子邮件的工作流程，这样开发者就可以像现在一样，使用 Emacs 进行所有的项目互动。Emacs 的共同维护者 Lars Ingebrigtsen 称这是 "最大的障碍"，并指出不能冒着失去现有贡献者的风险；"你能通过一个纯邮件的系统与 Gitlab 互动吗？" 虽然这个问题没有得到直接的回应，但 GitLab 的功能请求和其他讨论清楚地表明，答案是 "不能"，至少目前是这样，而且目前还不清楚是否有任何实际工作在进行来改变这种情况。
Web advantages
Philip Kaludercic 反对人们所说的使用 web 进行开发任务实际上更容易的说法，这是那些习惯于电子邮件风格的人的常见反应。同样，他说，虽然开发过程的各个部分都分布在不同的地方，但它们有一个重要的特点：都是电子邮件信息。他建议，"对邮件列表开发方式的偏见可能是不合理的"，但 Ingebrigtsen 说，这里还有一些其他因素：
看起来，直接发送 patch 应该更容易，但我们得到的反馈显示，对一些开发者来说，这并不容易。许多人根本不使用邮件进行开发，他们所习惯的是 GitLab/Hub 的方式。
因此，对他们来说，通过点击网页浏览器来进行开发就更容易，他们感觉更安全和熟悉。
另一方面，Jim Porter 解释说，作为相对来说开始不久的贡献者来说对使用基于电子邮件的工作流程的畏惧感是真实存在的，但事实证明，要适应其实也并不难。他说使用邮件列表来维护一个项目的话可能会有所不同，"但我并不需要做这些事情，所以对我来说不是个问题"。他确实提出了一些文档可能需要改进的地方，从而方便那些习惯于 pull request 式工作流程的人，并且打算提出一些文档 patch。但是 Tim Cross 认为电子邮件对于年轻的开发者来说是一个无法接受的方案：
我认为几乎所有的开发者都是被迫接受电子邮件方式的，但[越来越多]的人不再使用它。通常，所有的讨论、通知、评论等实际上都是通过移动 "应用" 来进行的。对于这些用户来说，登录收件箱是有些不爽且不方便的，因为他们的收件箱里有许多毫无意义的旧邮件/通知/警报，他们其实已经通过其他渠道看到或者收到了。对于这些用户来说，他们拥有电子邮件地址的主要原因是为了在他们使用的网络服务的 "login" 框时需要填写才用的。告诉这些用户要使用电子邮件来提交 patch，非常类似于我刚开始使用电子邮件时被告知必须通过 snail mail 来发送真正的信件一样。
Fleischer 表示赞同，他指出，他已经 30 多岁了（是 Cross 自己报告的 60 多岁的一半而已），但他已经只有在身份识别和接收官方文件的时候才使用电子邮件了：
我并不通过邮件与家人、朋友或同事交流。就我个人而言，我认为它很过时，默认情况下既不安全，也不私密，一致性非常不好（HTML 的渲染比起文本来说不确定性很大，有多个 MUA[mail user agent]），我完全无法想象把它作为一个软件工程（software engineering）工具来使用。
电子邮件的安全性（security）不好这个观点受到了很多人的反对，尤其如果是跟那些以应用程序为中心的替代方案相比。Zaretskii 说，"电子邮件的 security 问题早就解决了"，他工作的地方使用的基于电子邮件的工作流程使得他所在的公司能够做的比那些不使用电子邮件的合作伙伴和竞争对手更加好。然而，Cross 对电子邮件的安全性提出了尖锐的反对意见：
不管人们怎么说，电子邮件的安全问题其实并没有得到解决。它仍然是通过社会工程来进行攻击的主要载体之一，是[勒索软件]感染的主要载体，隐私[泄露]频繁来自于此，也是用来将敏感数据带出公司的常用手段。仅仅是对邮件进行加密，这对大多数用户来说就是过于复杂了，对大型的公司来说来说是管理噩梦。
Stefan Monnier 认为问题不在于电子邮件本身，而在于邮件列表令人畏惧：
我认为问题不在于电子邮件本身，而在于邮件列表的使用。根据我的经验，不愿意使用电子邮件的原因是，他们觉得可能是在向大量人员发送电子邮件是不太放心的。相比之下，在论坛上发贴就不一样了，它并未强加给任何人（在他们看来），因为那些阅读者必须主动去查看才会看到。
[当然，这种看法并不合理，真的，但是人们的看法总是不那么理性的。]
Clément Pit-Claudel 说，基于电子邮件的工作流程还是存在一些问题，而 forge 式开发可以对这些问题带来改进。其中之一是发出去的错误内容如果是在网站上的话，可以再次编辑，而邮件列表则不然；状态跟踪和维护者的一些任务也可能被简化。但 Zaretskii 也很快指出了他所看到的 web 界面的各种缺陷。他不认为增加 GitLab（或类似的东西）会给维护者带来什么好处，它只是 "更欢迎临时贡献者"，这一点是有价值的，但对现有的 Emacs 开发者的好处就不那么明显了。
无论最后做出什么选择，Stallman 都认为不推荐使用 "online dis-service" 来进行 Emacs 开发。增加一些辅助机制是可以的，但电子邮件必须一致保持可用：
如果用户可以选择通过电子邮件以外的其他界面与维护者和开发者进行交流，这也是不错的选择。(但当他们中的一些人使用这种方式时，也决不能强迫维护者和开发者也使用。
Multiple workflows
没有办法客观地判定哪种开发方式更加好用，Fleischer 说，所以讨论这一点的话是不会有结果的。"我可以客观地说，一种工作流程的形式比另一种更受欢迎，所以人们会更熟悉。" 谈话很快转向支持多种工作流程；由于 GitLab 没有什么进展，所以人们对 sourcehut 进行了更多讨论。
我们注意到 2020 年的两个讨论话题；一个是 sourcehut 的创建者 Drew DeVault 根据 GNU ethical repository criteria（伦理仓库标准）对 sourcehut 托管服务进行的自评，另一个是讨论使用 sourcehut 进行 Emacs 开发（或者是直接使用它的服务，或者 GNU 系统上托管其代码）。在后一个话题中，基于电子邮件的工作流程可以很好地支持起来，"但类似 GitLab/Github 的功能呢？"，Zaretskii 问。DeVault 引用了一段视频，展示了 "类似于 Github/Lab 的 pull/merge-request 流程的 sourcehut 工作流"。
这引发了对 sourcehut 在 Emacs 开发方面的所需能力的进一步讨论。Gutov 指出，与 "Git**b 工作流程 " 相比，他指出了一些差异是相对来说 "不舒服的地方，或者说是缺点"。这场讨论继续讨论了其中的一些领域，DeVault 参与了讨论，并对改进 sourcehut 当前功能从而满足 Emacs 项目的需求表示出了相当多的兴趣。在另一个小话题中，他总结了目前的状况：
首先，我们非常乐意在我们的服务上直接托管 emacs，或者支持在你们自己的基础设施上来使用我们的软件。考虑到 emacs 是一个以电子邮件为主导的项目，它应该或多或少能与每个人现有的工作流程配合，随着时间的推移，我们正在改进 web-based 方式的体验，这应该会让越来越多的用户可以参与 emacs 的开发，而不需要强迫维护者或那些喜欢以电子邮件为主工作流程的人来改变他们的工作流程从而[适应]GitLab 这样的一个平台。至于讨论到我们这个方案是否真正 free，这一点来说我们一定得分很高，因为整个服务都是自由软件，大多数是 AGPL。
他确实注意到 sourcehut 的 bug tracker 的工作方式与现有的 bug tracker 有所不同，后者是基于 Debian Bug Tracking System（BTS）的一个旧版本。但确实计划要使 sourcehut 的 bug tracker 要 "更加方便电子邮件方式"。虽然 sourcehut 和 GNU 的理念很相似，但 Stallman 仍然希望不要把 Emacs 托管在这个服务上：
我认为 Drew DeVault 的说法是正确的，他的理念与我们的很接近。如果我们不得不使用一些外部托管服务的话，我很可能说没有比他更好的选择了。(我不想在不知道其他选择是什么的情况下批评它们；它们可能同样好）。但我们更加希望把它放在 GNU 服务器上，由 GNU Project 的人管理。
正如 DeVault 在之前提到的，并不要求必须使用 sourcehut 官方服务：
你可以在 GNU 服务器上运行 sourcehut 软件，它是 100%的自由软件，主要是 AGPL。我鼓励你这样做。
Gutov 说，采用 sourcehut 的话总体是一件好事，但 sourcehut 中仍有一些目前缺少的功能，很难用电子邮件的方式来添加进来：
例如，Gitlab 在浏览器中的那些会改善大家生活质量的功能，我以前认为很难通过电子邮件方式来实现（例如代码审查工作流程，包括 inline comment 和来自 branch 的更新信息；会自动更新的 CI 状态报告以及指向相关编译工作的链接；对 message 的编辑），可以预见的是，这些功能都不会有。
人们正在努力描述 Emacs 希望在 sourcehut（或它可能采用的其他 forge 工具）中实现的各种基于网络的功能，以便让习惯 web-based 工作流程的用户感到熟悉和满意。Fleischer 列出了其中一些种类的功能。但是一些回复者仍然不完全相信增加对 web-based 工作流程的支持会带来更多更好的贡献内容。João Távora 根据他观察到的情况发表了一些看法：
在最近的 $DAYJOBs 工作中，我经常在用 GL/GH 这两个平台，随意使用它们，没有限制。在最近的这些经历中，这些平台不可否认的更加符合时代特性，以及对新人的友好性，似乎并没有转化为更好的代码质量、讨论质量在任何形式上对敏捷开发带来帮助。再说一遍，这只是一个传说而已，你可能把它当做是一种真实存在的好处，但事实上，我相信 Emacs 开发中使用的 "缓慢"、让人感到不熟悉的、奇特、老派的方法（不管你怎么称呼它），实际上可能是 "我们袖子里的王牌"，而并不仅仅是为了安抚那些已经使用很多年这种方法的人而已。
不过相反的观点也有，Pit-Claudel 在他工作中的一个转用 GitHub 的项目中看到了相反的情况，但他也告诫说，很容易对这方面的好处看得过于重要了：
这些好的变化其实并没有说明，是任何 "现代的" 工作流程都会有帮助，还是说因为网络效应（如果你已经有了一个账户，并且已经熟悉了用户界面，那么进行贡献的门槛就会降低）， Github 就是典型。
事实上，我的经历本身甚至无法确认到底是搬家本身有帮助，还是说搬家只是在采用更受欢迎的方法以及努力吸引贡献过程中的一个无关紧要的行为。
对于 Monnier 来说，工具如何选择现在其实不是个问题。与其继续研究其他选择，他只希望继续对 Sourcehut 进行评估：
阅读这个讨论让我意识到为什么我支持 SourceHut：它是我看到的这类工具中唯一一个目标与我们完全一致的。无论是在思想哲学上（其他大多数工具只是碰巧是自由软件 Free Software 而已，但在哲学上更加靠近 Open Source 这个概念）还是在技术上（它的目标是对电子邮件达到一流的支持，同时尽可能提供其他系统已经具有的很吸引人的 web 功能）。
所以在这个阶段，我个人认为没有必要寻找其他工具了。我只想知道如何让我们开始使用 SourceHut（即如何解决可能在阻碍我们的问题，例如在 GNU 机器上建立和运行第一个实例，开始 "同时并行" 使用这个机制，这样就能在我们真正迁移之前看到我们有哪些需要修复/改进/添加的，等等）。
很明显，任何改动（如果确实会有改动的话）都需要支持基于电子邮件的工作流程，与今天的工作方式保持一致（或尽量基本上一致），但同时增加其他的工作流程方式可能就是 "nice-to-have" 的性质了。斯托尔曼指出，将电子邮件作为最优先的选择，这既有实际的考虑，也有道德方面的考虑：
在你试图使用 web forum 这些论坛的时候，你还需要有一个互联网连接。而发送电子邮件就不一样了。
[……]要在一个 web forum 上建立一个账户，那么你就必须以它所要求的方式来使用该平台。你必须接受它的 terms 与 condition 各种条款，这些可能对我们来说在道德上是不可接受的。
当你发送电子邮件时，你使用的是你自己选择的工具和平台，这也是你前一天向不同的 forum 发送邮件所用的工具和平台。
Network effects
尽管有些人期望 sourcehut 发展到可以同时满足新老两派开发者的程度，但对于今天的许多年轻开发者来说，这可能还是太遥远了。GitHub（GitLab 也算是，虽然程度上仍有不及）的网络效应远远超过了 sourcehut，而且很可能这些其他 forum 的用户会因为看到 sourcehut 与之前平台的一些差异就不愿加入。正如 Ingebrigtsen 所说：
当我们找到一个足够好的系统时，Emacs 就会改用新的系统，同时提供电子邮件工作流程（供那些喜欢这种工作方式的人）和非电子邮件工作流程（供另一些喜欢那种方式的人）。
我们还没有找到这样的系统。sr.ht [sourcehut]也许是一个选择，但我的第一印象是它与 GitHub/Lab 差别太大了，真的。
最后，可能还是要看 Emacs 开发者社区是否有精力开始与 sourcehut 合作（或找其他一些替代方案，虽然目前看来可能性小得多）。即使是仅仅让它达到完全支持基于电子邮件的工作流程的程度，显然也是需要做一些工作的（例如，bug tracking 的改动）；还需要更多的 web 功能来吸引 Git**b 的用户，这甚至需要更多开发工作。现在还不清楚做这些工作会不会使最终情况发生重大改变。那些临时经过的贡献者，甚至包括那些比较认真在做 Emacs 开发的人，对注册另一个网站并学习以及习惯其界面、特性都可能并不会有兴趣。
当然，并不是只有 Emacs 觉得需要让未来的工作流更加现代化。例如，Python 在很大程度上已经转向 GitHub，而 Linux 内核也正在慢慢进入这个世界。其他项目可能也在为之努力。如果说要对未来在某种程度上进行预测的话，我们只能说，也许 20 或 30 年之后，基于电子邮件的工作流程将被淘汰或差不多要被淘汰了。从现在开始，直到那个时刻之前，对许多存在了比较久的项目来说，都会有不少迷茫的探索。
全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。
长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～