以下为译文：
这篇文章我写得十分艰难，一来是感情上的纠结，二来是我没有时间。因此，在阅读本文时请注意，我无意触怒任何为Debian做出了贡献的人，我只是想表达我对Debian太过于失望而决定放手的原因。
到目前为止，Debian出现在我的生命中已经超过10年了。
几个星期前，我在苏黎世Debian聚会上遇见了一些多年未见的老朋友。在骑自行车回家的路上，我突然发现我们讨论的主题与我们上次的讨论大致相同。出于对开源社区的尊敬，我们绕了个圈子先探讨了systemd的好处，然后回到了Debian的讨论，最后兴致所至还谈到了Debian的民主以及他们在理论和实践上的失败。诚然，最后一个话题有点像瑞士。
我说这些不是对Debian聚会有异议，而是因为通过这次聚会我开始反思最近对Debian的感觉，还有它是否适合我。
最终，我做出了一个本应在很久以前就已经做出的决定：我会将有关Debian的工作减到最少。
这是什么意思？
在接下来的几周内，我将：
将包转交给相应的维护团队
从其他维护者的包的Uploaders字段中删除自己的名字
对于那些只有我在维护的包，那就任其自生自灭吧
我将尽最大努力维护manpages.debian.org服务（https://manpages.debian.org/）和codesearch.debian.net服务（https://codesearch.debian.net/），但是随时欢迎别人来帮忙。
请所有人都当我永远休假去了。我会尽力解决管理的问题（例如许可转移等），如果有人直接向我提问，而且问题很容易回答的话，我也会尽力回答。
为什么？
当年加入Debian的时候，我还是一名学生，所以我有大量的业余时间。现在，经过5年多的全职工作，我从日常的工作中学到了很多知识，包括大型软件工程项目的工作原理，而且我也明白自己多么地喜欢我的计算机系统。我非常清楚这些日子以来的闲暇时间我是如何度过的。
我会在以下各小节中逐一介绍我所面临的主要困难，讨论顺序不分先后。其中有些困难有一些相互影响——例如，如果改动后的效果更好，那么我们就有机会将包转换成更方便的机器读取。
Debian的变更流程
最近几年，我目前的团队在整个代码库中进行了各种大大小小的重构（涉及数千个项目），因此在关于如何有效地进行这些变更方面，我们学到了很多宝贵的经验。令我苦恼的是，Debian在各方面的工作方式几乎完全相反。我理解每个组织都不同，但我认为我的很多观点确实适用于Debian。
在Debian中，包的推送必须严格遵守一个文档——叫做Debian策略，还有个程序lintian用来保证该策略的实施。
虽然拥有一个lint工具（能实现快速、本地/离线的反馈）非常好，但最好的情况还是完全不需要lint工具。实施变更（例如C++团队为所有包引入了一个新的强化标志）的团队应该能够让我明确看到他们的工作。
然而，实际情况却恰恰相反，目前所有的包都由于lint而变得不干净，所有的维护者都需要阅读新内容是什么、可能会造成怎样的破坏、是否有影响以及怎样的影响、手动运行一些测试、最后再决定是否采用。整个过程的工作量巨大，而且还需要手动执行机械的更改。
特别是，在Debian的变更模型中，所有更改的工作都会分派给包维护者。在工作中，我们发现相反的工作方式更好：即让负责变更的团队自行选择那些能影响更多用户的更改，这样可以显著地提高效率，从而降低总体的成本和时间。当然，有些例外情况（例如滥用语言功能的大型项目）仍应由各自的所有者负责，但重要的是默认情况应该是相反的。
Debian缺乏管理重大变更的工具：很难用程序的方式处理包和存储库（请参见下一小节的内容）。最近一次发送过来要求审核的更改是一个附带补丁的bug报告。我认为接受bug报告更改的流程太复杂，然后开始尝试mergebot，但只有Guido曾经表示对该项目感兴趣。
在文化方面，Debian的评论和反应都很慢。凡事都没有截止期限。有时我会收到电子邮件，通知我说我在几年前（！！）发送的补丁现在终于合并了。只有短短数周的项目拖到了数年，对我来说这是一个巨大的消极影响。
有趣的是，你可以看到缓慢的线上活动也影响到了线下的文化：我不想在第一次听到systemd后，过10年之久再讨论它。
最后，如果有人坚持拒绝合作，那么你做出的变更很容易就会被一拖再拖。我举一个典型的例子：rsync，其维护者完全出于个人的喜好拒绝我的补丁包使用debhelper。
赋予个人维护者如此大的自由，导致我们无法开展提高构建Debian软件包抽象级别的项目，这反过来又让工具更加困难。
更好的方式是什么？
作为一个项目，我们应该努力实现更多的统一。统一性并不能完全去除实验，它只是改变了两者的平衡，从简单的实验和难度较高的自动化变成了难度较高的实验和简单的自动化。
我们的文化需要从“这个包归我管，你不能碰”转变为共同的所有权意识，项目中的任何人都可以很容易地贡献（经过审查的）变更，而不必凡事都要通过个人维护者。
支离破碎的工作流程和基础设施
Debian似乎更倾向于采用分散式的方法，而不是集中式的方法。例如，每个包都保存在单独的代码库中（而不是在一个统一的代码库中），每个代码库都可以使用随意地代码管理工具（通常是git和svn）或者根本不使用代码管理工具，而且每个代码库都可以托管在不同的站点上。不用说，你在这样的代码库中所做的工作也因团队而异，甚至是团队内部都有微妙的不同。
而在实践中，我们很少会用到非标准的托管方式，这并不是因为成本问题，而是考虑到将变更自动化时的困难性。你不能使用GitLab的API来创建合并请求，而是必须通过一个完全不同的、非常复杂的系统，而这个系统会出现间歇性（或永久性！）无法访问代码库的情况，或者无法从提交上来的补丁（bug报告、合并请求、拉取请求、电子邮件等等）中抽取差异。
各色迥异的工作流程不仅仅是一个临时问题。我在DebConf 13期间参加了有关不同git工作流程的一个漫长的讨论，并在此期间经历了类似的讨论。
我未能清楚地记住不同工作流程的所有细节。每当我遇到一个与我的工作方式截然不同的包时，我就会非常沮丧，我不得不重温日常工作的各个方面。
在注意到Go包团队（我最初的团队）工作流程的支离破碎后，我尝试采用这篇文章（https://go-team.pages.debian.net/workflow-changes.html）中介绍的工作流程更改提议来解决这个问题，但没能成功。虽然我愿意贡献时间和精力，但周围的工具缺乏有效的自动化，且变化速度缓慢，这抹杀了我的动力。
陈旧的基础设施：包的上传
如果想在Debian中创建包，你需要通过匿名FTP上传GPG签名的文件。还有几个定时（例如dinstall的运行时间为UTC 01:52、UTC 07:52、UTC 13:52和UTC 19:52）运行的批处理作业（队列守护程序、unchecked、dinstall，以及其他等）。
根据时间安排，我估计你可能需要等待7个小时（!!）以上，你的包才能变成可安装的状态。
对我来说更糟糕的是，针对上传的反馈是异步的。我喜欢做一件事，那就做完它，然后再做下一件。然而，由于没有良好的技术，当前的设置需要等上好几分钟，而且任务切换的开销很大。你可能觉得几分钟也没什么大不了，但是我每天在Debian上花费的时间都以分钟来衡量的话，那么会对工作的生产力和乐趣产生巨大的影响。
最后一次有关于加快这一流程的沟通是2008年ganneff的这篇文章（https://lists.debian.org/debian-project/2008/12/msg00014.html）。
更好的方式是什么？
利用一个Web服务取代匿名FTP，通过该服务接收我的包，并在响应中返回权威的决定：拒绝或接受。
对于接受的包，通过一个状态页面来显示包的状态，以及可以通过镜像网络提供包的时间。
包应在构建完成后，几分钟内即可进入可访问状态。
陈旧的基础设施：bug追踪
我非常害怕与Debian的bug追踪系统交互。debbugs是一款始于1994年的软件，目前仅供Debian和GNU项目使用。
Debbugs负责处理电子邮件，也就是说它的处理是异步的且很麻烦。尽管我们在Debian最快的机器上运行了Debbugs，但是它的Web界面加载速度依然非常慢。
尤其是bugs.debian.org的Web界面是只读的。为reportbug（1）（https://manpages.debian.org/stretch/reportbug/reportbug.1.en.html）设置有效的电子邮件，或手动处理附件都是一件极其麻烦的事情 。
由于一些我不理解的原理，每次与debbugs的交互都会引发很多电子邮件。
除了技术实现之外，我永远也记不住Debian使用伪包来处理bug和进程的不同方式。我几乎很少用到它们，所以也没心思搞清楚如何设置它们，或它们使用了多少内存，但是它们却给我频添烦恼。
更好的方式是什么？
Debian从自定义的bug跟踪程序切换到（任何一种）完善的工具。
Debian围绕流程提供自动化。如果能以bug报告的形式提供这个过程中的文件跟踪和产出，那便再好不过了，而且主界面（例如Web表单）应该方便使用。
陈旧的基础设施：邮件列表归档
令我感到困惑的是，时至2019年，我们仍然没有一个方便浏览的邮件列表的归档。电子邮件在Debian中的使用尤为广泛，所以感觉这很讽刺啊。为了掩盖这个问题，我们使用了Gmane，但在过去几年中Gmane可谓是非常不稳定。
我设法提供了一个线程列表的归档，但我们的列表管理员似乎并不关心，而且也不想支持这个项目。
Debian很难机器读取
虽然肯定有办法通过程序的方式处理Debian包，但这种体验一点也不愉快。一切似乎都十分缓慢而且很麻烦。我只选了三个简单的例子来说明我的观点。
Debiman需要piuparts的帮助，才能分析每个包显示联机帮助页等内容的替代机制。这是因为维护者的脚本通过调用shell脚本来修改备用数据库。如果没有实际安装包，你就无法得知它对备选的数据库做了哪些更改。
pk4需要维护自己的缓存，才能根据包的名称查找包的元数据。其他工具在每次调用时都需要从头开始解析apt数据库。一个恰当的数据库格式，或者至少是二进制的可交换格式都需要花费很大力气。
Debian Code Search希望尽快接受新包。我们曾经用过Debian的fedmsg实例，但似乎现在已经不见了。目前还不清楚从哪里获取新包的通知，以及获取这些包的最佳位置。
复杂的构建堆栈
请参阅我的这篇文章“Debian软件包构建工具”（https://michael.stapelberg.ch/posts/2016-11-25-build-tools/）。让我感到困惑的是其他人不认为工具的蔓延是个问题。
非常痛苦的开发者体验
到目前为止，本文讨论的大多数都是开发Debian的体验，但是正如我最近的这篇文章“Debian中的调试体验”（https://michael.stapelberg.ch/posts/2019-02-15-debian-debugging-devex/）所描述的那样，使用Debian进行开发的体验也有很多不足之处。
其他的想法
到这里，这篇文章已经很长了，希望你已经对我的动机有了一个粗略的了解。
尽管我上面描述了Debian的种种缺点，但压倒骆驼的最后一根稻草实际上还是其缺乏积极的前景。我的很多想法在我看来都很有吸引力，但是，根据以前的项目情况，我觉得在Debian的项目中这些想法不可能会实现。
我打算发布一些有关具体改进操作系统的文章。敬请关注。
最后，我希望这篇文章能够给部分人一些启示，让他们来改善Debian的开发者体验。
原文：https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/
本文为 CSDN 翻译，如需转载，请注明来源出处。作者独立观点，不代表 CSDN 立场。
