译者：本文是著名开源开发人员（ GitHub个人资料 ）Michael Stapelberg的个人博客文章的翻译，他为Debian的发展做出了重要贡献。
从情感的角度来看，这篇文章很难写，但是我没有将自己局限于“一封简短的信，因为我没有时间。” 请在阅读本文之前，请记住，我本着最好的意图编写本文，但不要为自己设定挫败或轻视一位开发人员的贡献的目标。 相反，我想解释一下为什么我的挫败感超过了所有可接受的值。
Debian成为我生命中的一部分已有10年了。
几周前，在苏黎世举行的Debian会议上，我遇到了很多年没见面的老朋友。 当我已经骑着自行车回家时，我突然意识到，我们讨论过的所有话题都归结为上次与他们讨论的话题。 我们讨论了systemd的优点，它再次引起了开源社区的关注，并涉及了Debian中的过程主题。 最终的结果是对民主本身以及相应的理论和实践错误的讨论。 但是，实际上，这纯粹是瑞士的话题。
这不是对过去的混战的评论，我只想解释是什么让我想到了我目前对Debian的态度以及它是否适合我。
因此，我做出了很久以前必须做出的决定：我正在减少对Debian开发的参与。
这是什么意思？
在接下来的几周内，将会发生以下情况：
- 我将重要的软件包传递给维护的命令；
- 我将从包含其他维护者的Uploaders软件包中删除自己；
- 我唯一陪同的包裹将成为孤儿。
我将尝试继续维护
manpages.debian.org和
codesearch.debian.net服务页面，但是我会非常感激这方面的帮助。
如果您有任何疑问或任何任务，请考虑我正在无限期休假。 我将尝试参与一些管理问题（例如，许可证的转让）和亲自处理给我的任务，但前提是该过程不会花费很多时间。
怎么了
加入Debian时，我还在学习，也就是说，我有很多空闲时间。 现在，经过5年的全职学习，我学到了很多东西-无论是在大型软件开发项目中如何工作，如何工作，以及在理解我对计算机系统的个人偏好方面。 现在，我清楚地知道我将空闲时间的一小部分花在了什么上，以及在一天结束时剩下了什么。
以下各节将重点介绍伤害作为开发人员的我的事情。 该列表以随机顺序给出。 例如，其中一些问题会相互影响-如果更好地进行系统更改，我们将有机会使机器更容易处理软件包。
Debian变更流程
在过去的几年中，我目前的团队一直在整个代码库中进行各种重组（影响数千个项目），因此我们就如何有效地进行这些更改获得了很多宝贵的经验教训。 令我烦恼的是Debian在几乎所有方面都以几乎相反的方式工作。 我赞赏每个项目都不同的事实，但是我认为下面列出的许多要点总体上适用于Debian。
在Debian中，使用称为Debian Policy或其软件版本
Lintian的文档朝着正确的方向开发软件包。
尽管皮棉很容易获得快速的直接或本地/自治反馈，但最好甚至根本不需要这样的工具。 例如，C ++命令为所有软件包引入了新的安全性标志，它也应该能够使其工作对我来说透明（
根据GitHub个人资料判断，Go的主要语言是Michael，大约是Trans。 ）。
取而代之的是，现在所有的包裹都是“脏”的（原来是-棉绒不洁的）：所有服务员都应该读懂这个新东西是什么，它如何破裂，是否会影响他们的整体工作以及（如果这样）如何。 然后，您需要手动运行一些测试，最后放弃所做的更改。 所有这些都是包装之间的大量开销和手动机械操作。
在Debian模型中，
发布新闻的
决定取决于附带的软件包，而不是开发人员。 在我的主要工作中，我们发现相反的做法效率更高：如果书面更改影响了很大一部分用户，则开发人员必须决定其实现需求。 这种方法使项目的开发更有效率，并减少了时间和人工成本。 当然，例如在使用语言芯片的大区域中，也有例外情况，应由各自的所有者-策展人来照顾，但重要的是默认情况下所有内容都应与现在有所不同。
Debian
缺乏进行重大更改的工具 ：使用程序难于使用零散的软件包和存储库（在下面的部分中对此有更多的了解）。 与默认的“将更改发送给审阅”最接近的事件是打开错误报告并附加了补丁的过程。 在我看来，接受错误修复的现有过程太复杂了，我开始开发一个合并机器人，但只有Guido和其他人对此没有兴趣（
显然，作者谈论的是另一位Debian开发者Guido agx Gunter ， -大约 。
从字面上看，对推送的反应以及相应的反馈反馈都很慢。 根本没有最后期限。 有时，我会收到一封电子邮件，通知我几年前发送的补丁（!!!）终于包含在内。 这将每周的项目延长了很多年，对我而言，这是一个强大的动力。
奇怪的是，但是乌龟在线活动的实践也被投射在离线文化上，我不想在我第一次听说系统化系统10年后再讨论它的优点。
最后，任何不同之处都会被那些不同意，最终拒绝合作的人拖延。 这种情况的典型示例是rsync。 策展人拒绝了我的补丁，仅出于自己的信念，这些补丁为软件包增加了debhelper支持。
授予个人维护者一定程度的个人自由，可以防止我们所有人的项目参与者都提高Debian构建的抽象水平，这反过来又使开发工具复杂化。
在理想世界中会是什么样子？
- 作为一个项目，我们必须争取统一。 毕竟，统一并不排除实验；它只是将当前在更简单的实验和更复杂的自动化之间的折衷变为更复杂的实验和更简单的自动化之间的折衷。
- 我们的发展文化应摆脱“这个包是我的家，您敢于触摸”的范式，这是一种所有权的常识，在这种范式中，任何参与者都可以轻松进行或验证更改，即使没有陪同他们的策展人参与也是如此。
为了了解成功的大型变更（补丁）可能是什么样子，我建议您阅读同事Hyrum Wright
的演讲
“ Google的大规模变更：五年大规模迁移的经验教训”。零散的工作流程和基础架构
Debian通常比集中式方法更喜欢分散式方法。 例如，单独的软件包存储在单独的存储库中，每个存储库可以使用任何SCM（通常是git和svn），也可以根本不使用。 另外，每个存储库都可以托管在任何站点上。 当然，每个存储库的内容在团队之间甚至团队内部也略有不同。
在实践中，非标准托管选项很少使用，因为它们不能证明其成本合理，但在尝试使对软件包进行更改的过程自动化时，常常足以引起极大的痛苦。 因此，无需使用GitLab API创建合并请求，您需要开发一个完全不同，更复杂的系统，该系统可定期（或持续！）无法访问的存储库，提取已交付补丁中的差异（错误报告，合并请求） ，提取请求）等等等等……
根本不同的开发过程不仅浪费时间。 在DebConf 13期间，我参加了有关各种git开发过程的长时间讨论，然后我意识到当时正在进行类似的讨论。
就个人而言，我无法记住有关各种开发方法的足够详细的信息。 每当我碰到一个不像我的包裹那样有效的包裹时，都会感到非常沮丧，因为我必须重新检查其工作的各个方面。
我在自己的Go打包团队中注意到工作流程的类似碎片，并试图通过
对工作流程的更改提出建议来修复它，但是我无法实现它们。 尽管我愿意花费自己的时间和精力，但是缺乏有效的自动化和工具的低更改率，扼杀了任何动力。
不推荐使用的基础结构：下载程序包
当您想让软件包在Debian中可用时，您可以通过匿名FTP上传GPG签名的文件。 有几种类型的任务（以固定的时间表运行）（例如，队列守护程序，未选中，dinstall和其他）（例如，dinstall在01:52 UTC，07：52 UTC，13：52 UTC和19:52 UTC运行）。
我计算出，根据一天中的时间，您可以等待7个小时以上（!!!），然后再安装软件包。
但是对我而言，最糟糕的是，反馈在加载方面是异步的。 我喜欢做某事，结束它，然后继续下一个作业。 当前的设置需要很长的等待时间，实际上，在没有良好技术原因的情况下，任务之间的切换成本很高。 您可能会注意到，几分钟并不是很重要，但是如果以分钟为单位来衡量一天中我可以花在Debian上的所有时间，那么对所完成的工作感知我自己的表现和满意度非常重要。
我能找到的关于加快此过程的最后一条消息是2008年
George Ganneff Jaspert的
帖子 。
在理想世界中会是什么样子？
- 匿名FTP将由接受我的软件包并在响应中返回接受或拒绝该软件包的正式决定的Web服务取代。
- 对于收到的软件包，会有一个页面显示构建状态和通过镜像网络提供软件包的时间。
- 包装应在组装完成后的几分钟内提供。
弃用的基础架构：错误跟踪器
恐怕要与Debian错误追踪器互动。 Debbugs是1994年以来的一段代码，目前仅由Debian和GNU项目使用。
调试过程基于电子邮件的使用，也就是说，它们是异步且繁琐的。 尽管事实上它可以在Debian项目中拥有最快的机器上运行（嗯，他们告诉我上一次提出该主题的时间），但是它的Web界面加载速度却非常慢。
值得注意的是，bugs.debian.org上的Web界面是只读的。 为
reportbug（1）设置电子邮件
工作区或手动处理附件是一个非常严峻的挑战。
由于某些我不了解的原因，每次与调试程序的交互都会导致
大量对话 。
除了技术实施之外，我也丝毫不记得Debian使用伪生成软件包处理错误和过程的各种方式。 我对它们的需求很少，最终我完全无法记住它们，并且确切地记得它们的功能和使用方式，但是我偶尔会遇到它们，所以这种变化很烦人。
在理想世界中会是什么样子？
- Debian将从跟踪错误的非标准方式转换为已经解决的（任何）方式。
- Debian使这些过程自动化。 主界面应该更方便（例如，Web表单）。
不推荐使用的基础结构：电子邮件通讯存档
我感到困惑的是，2019年我们仍然没有方便的工具来查看邮件中的存档讨论主题。 与Debian一样，电子邮件和会话不再在任何地方使用，因此甚至具有讽刺意味。 使用
Gmane似乎可以解决此问题，但从
某种程度上来说，它的可用性在过去几年突然变了（现在，在撰写本文时，它根本不起作用）。
我试图创建一个多线程存档，但是我们的工作表母版并没有给他们留下深刻的印象，并且拒绝支持该项目。
机器很难与Debian一起使用
尽管很明显，您可以通过编程方式使用Debian软件包，但是这种体验并不令人愉快。 一切似乎都缓慢而笨重。 我选择了三个小例子来说明我在这个问题上的立场。
debiman需要
piuparts 帮助分析每个软件包的替代机制以显示文档页面，例如
PSQL（1） 。 这是必需的，因为这些脚本通过调用Shell脚本来修改备用数据库。 但是，如果没有实际安装该软件包，您将不会知道它会产生什么变化。
pk4必须维护自己的缓存，才能根据其名称搜索包元数据。 其他工具会在每次调用时从头开始分析apt数据库。 正确的数据库格式，或者至少是二进制交换格式，对于此过程非常重要。
Debian Code Search希望尽快收到新软件包。
fedmsg实例先前已使用，但不再存在。 目前尚不清楚在哪里接收新软件包的通知，以及在哪里最好接收它们。
复杂的构建堆栈
在这里，您可以阅读我的文章
“ Debian软件包构建工具” 。 真正让我担心的是，增加工具的数量并不是一个问题。
对于开发人员而言，Debian令人痛苦
我提出的大多数问题都与Debian开发经验有关，但是，正如我最近在《
Debian Debug Debugging Experience》帖子中所述，
使用Debian的开发经验也有很多不足之处。
我有更多的主意
原来这篇文章篇幅很大，但我希望您对我的动机有所了解。
尽管我在上面描述了许多特定的缺陷，但棺材盖上的最后一钉钉子是对未来缺乏乐观的看法。 我还有其他想法似乎对我很有说服力，但是基于我之前项目的进展情况，我认为我不能在Debian项目中实施其中的任何一个。
我打算在我的博客上发布更多有关改进操作系统的特定方法的文章。 快点
最后，我希望这篇文章能激发一个人，最好是一群人，以改善Debian开发人员的生活。