无论是从情感上还是在“我本来要写一封简短的信，但我没有时间”的意义上，这篇文章都很难写。因此，请在阅读本书时假设最好的意图-我的目的不是让任何人对他们的贡献感到难过，而是要提供一些见识，以使我的挫败感最终超过极限。
几个星期前，在缺席了多年之后，我在苏黎世Debian聚会上拜访了一些老朋友。在我骑车回家的路上，我发现我们的讨论主题与我上次访问时有很大的重叠。我们讨论了systemd的优点，绕开了尊重开放源码社区的想法，回到了Debian的流程中，最终达到了民主制及其理论/实践上的失败。不可否认，最后一个可能是瑞士人。
我说这并不是要打断Debian聚会，而是因为它促使我反思Debian最近在调用什么感觉以及它是否仍然适合我。
因此，我终于做出了我应该早就做出的决定：我将对Debian的参与减少到最低限度。
我将尽最大努力维护manpages.debian.org服务和codesearch.debian.net服务，但是任何帮助将不胜感激。
出于所有目的和目的，请在度假时永久对待我。我将尽量解决管理问题（例如许可转让）和直接向我提出的问题，只要它们很容易回答即可。
加入Debian时，我仍在学习，也就是说，我有很多业余时间。现在，经过5年的全职工作，我的日常工作教会了我很多东西，包括大型软件工程项目中的工作原理以及我个人对计算机系统的喜欢程度。我非常清楚自己现在如何度过很少的业余时间。
以下各节以特殊顺序处理我认为的主要痛点。它们中的一些会相互影响-例如，如果更改工作得更好，我们可能有机会将软件包转换为更容易机读的方式。
在过去的几年中，我目前的工作团队在整个代码库中进行了各种大小的重构（涉及数千个项目），因此，我们已经学到了很多有关如何有效地进行这些更改的宝贵经验。让我感到不安的是，Debian在各个方面的工作方式几乎相反。我很高兴每个组织都不同，但是我认为我的很多观点确实适用于Debian。
在Debian中，软件包被称为Debian Policy或其程序化实施方案lintian的文件按正确的方向轻推。
虽然拥有棉绒工具（用于快速的本地/离线反馈）很棒，但甚至根本不需要棉绒工具甚至更好。进行更改的团队（例如C ++团队为所有软件包引入了新的强化标志）应该能够对我透明地进行工作。
取而代之的是，当前，所有软件包都变得不干净，所有维护人员都需要了解新事物，如何破坏，是否/如何影响它们，手动运行一些测试并最终决定选择加入。开销和跨包手动执行的机械更改。
值得注意的是，每次更改的成本均分配给Debian模型中的软件包维护者。在工作中，我们发现相反的方法效果更好：如果启用更改背后的团队来为尽可能多的用户进行更改，则他们可以大大提高效率，从而大大降低了总成本和时间。当然，例外（例如，大型项目滥用语言功能）仍应由各自所有者负责，但重要的一点是，默认值应与之相反。
Debian缺少进行大型更改的工具：很难以编程方式处理软件包和存储库（请参见以下部分）。与“发送更改以供审核”最接近的是打开带有附件补丁的错误报告。我认为接受来自错误报告的更改的工作流程过于复杂，因此启动了mergebot，但是只有Guidoever表示对该项目感兴趣。
在文化上，评论和反应很慢。没有截止日期。我有时会收到一封电子邮件，通知我几年前（!!）发送的补丁现已合并。这将项目从很少的几周变成很多年，这对我来说是一个巨大的动力。
有趣的是，您也可以在离线文化中看到缓慢的在线活动的人工痕迹：我不想在我第一次听说systemd的优点后10年就讨论这种优点。
最后，拒绝合作的保持者很容易将变更的速度大大降低。我的典型示例是rsync，其维护者拒绝我的补丁程序以使软件包纯粹出于个人喜好使用debhelper。
授予个体维护者如此多的个人自由，使我们作为一个项目无法提高构建Debian软件包的抽象水平，这反过来又使工具变得更难。
作为一个项目，我们应该努力实现更多的统一。均匀性仍然不排除实验，它只是将折衷从较容易的实验和较难的自动化变为较难的实验和较易自动化。
我们的文化需要从“这个包是我的领域，您如何敢于摸索”转变为一种共有感，即项目中的任何人都可以轻松地贡献（审阅）更改，而不必甚至让单个维护者参与。
要了解有关大型变更看起来如何成功的更多信息，我推荐同事Hyrum Wright的演讲“ Google的大型变更：大规模迁移5年的经验教训”。
通常，Debian似乎比集中式方法更喜欢分散式方法。例如，各个软件包都保存在单独的存储库中（而不是在一个存储库中），每个存储库可以使用任何SCM（git和svnare通用的）或根本不使用SCM，并且每个存储库都可以托管在不同的站点上。当然，您在这样的存储库中所做的工作也会因团队之间甚至团队内部的不同而有所不同。
在实践中，很少使用非标准托管选项来证明其成本合理，但在尝试自动执行对软件包的更改时，经常使用非标准托管选项会造成极大的痛苦。不必使用GitLab的API创建合并请求，您必须设计一个完全不同，更复杂的系统，该系统间歇性地（或永久地！）无法访问的存储库，并消除补丁程序交付中的差异（错误报告，合并请求，请求请求，电子邮件） ，…）。
截然不同的工作流程也不只是暂时的问题。在DebConf13期间参加了有关不同git工作流的长时间讨论，并发现与此同时也有类似的讨论。
就个人而言，我无法在脑海中保留足够多的不同工作流程的详细信息。每当我碰到一个与我的包装不同的包装时，都会极大地困扰我重新学习我的日常情况。
在Go打包团队（我开始了）中注意到工作流程碎片之后，我尝试使用工作流程更改提案来解决此问题，但未成功实现。尽管我愿意付出时间和精力，但是缺乏有效的自动化和周围工具的更换速度缓慢，这使我失去了动力。
当您想让软件包在Debian中可用时，您可以通过匿名FTP上传GPG签名的文件。有几个按固定时间表运行的批处理作业（队列守护程序，未选中，dinstall可能还有其他）（例如dinstall在01:52 UTC，07：52 UTC，13：52 UTC和19:52 UTC运行）。
根据时间的不同，我估计您可能要等待7个小时以上才能实际安装软件包。
对我来说更糟的是，您上传的反馈是异步的。我喜欢做一件事，完成它，转到下一件事情。当前的设置需要几分钟的等待和昂贵的任务切换，而没有很好的技术理由。您可能会认为几分钟不是什么大问题，但是如果以分钟为单位来衡量Ican每天在Debian上花费的所有时间，那将极大地影响人们的生产力和娱乐性。
关于加速该过程，我能找到的最后一封信息是ganneff在2008年发表的帖子。
匿名FTP将由Web服务代替，该Web服务将吸收我的软件包并在其响应中返回权威性的接受或拒绝决定。
对于已接受的软件包，将有一个状态页面显示构建状态，以及何时可通过镜像网络使用该软件包。
我害怕与Debian Bugtracker进行交互。 debbugs是一款软件（源自1994年），如今仅由Debian和GNU项目使用。
Debbugs处理电子邮件，这意味着异步处理和麻烦处理。尽管在Debian中可用的最快的计算机上运行（或告诉我主题何时最后出现），但其Web界面加载速度非常慢。
值得注意的是，bugs.debian.org上的Web界面是只读的。为reportbug（1）设置工作电子邮件设置或手动处理附件是一个很大的障碍。
由于我不了解的原因，每次与调试程序的交互都会导致许多不同的电子邮件线程。
除了技术实现之外，我也永远不会记住Debian对错误和进程使用伪软件包的不同方式。我需要他们足够少地建立关于如何设置它们或如何使用它们的工作记忆的心理模型，但是经常使它们烦恼。
Debian将提供流程自动化。以错误报告的形式显示过程的纸质痕迹和人工制品很棒，但是主要界面应该更方便（例如Web表单）。
让我感到困惑的是，在2019年，我们仍然没有一个方便浏览的邮件列表讨论存档。电子邮件和线程在Debian中的使用比其他任何地方都广泛，因此有点讽刺。 Gmane曾经为这个问题写过纸，但至少可以说，Gmane在过去几年中的供应情况很少（在我撰写本文时，这一数字已经下降了）。
我曾尝试贡献一个线程列表档案，但我们的列表管理员似乎并不在乎或不想支持该项目。
虽然显然可以通过编程方式处理Debian软件包，但体验却远非令人愉快。一切似乎都缓慢而繁琐。我仅选择了3个简单的例子来说明我的观点。
debiman在分析每个软件包的替代机制以显示其手册页时需要来自puparts的帮助。 psql（1）。这是因为维护者脚本通过调用shellscript来修改替代数据库。如果没有实际安装软件包，您将无法知道对替代数据库所做的更改。
pk4需要维护自己的缓存，以便根据程序包名称查找程序包元数据。其他工具会在每次调用时从头开始解析apt数据库。适当的数据库格式，或者至少是二进制交换格式，将大有帮助。
Debian Code Search希望尽快吸收新软件包。曾经有Debian的fedmsg实例，但是似乎不再存在。目前尚不清楚从何处获取有关新软件包的通知，以及从何处最好获取这些软件包。
请参阅我的“ Debian软件包构建工具”文章。确实使我感到烦恼的是，其他人不认为工具的泛滥成问题。
到目前为止，讨论的大多数要点都涉及到开发Debian的经验，但是正如我最近在我的文章“ Debian的调试经验”中所描述的那样，使用Debian进行开发时的经验也有很多不足之处。
在这一点上，这篇文章已经很长了，希望您对我的动机有所了解。
虽然我在上面描述了许多特定的缺点，但棺材中最后的钉子实际上是缺乏积极的前景。我有更多似乎对我有吸引力的想法，但是根据我以前的项目进展情况，我认为我无法在Debian项目中实现任何这些想法。
我打算在这里发布更多有关改进操作系统的特定想法的文章。敬请关注。
最后，我希望这篇文章能激发人们，最好是一群人，以改善Debian的开发人员体验。