谁负责旧软件版本的错误报告？

# 谁该为旧软件版本的bug报告负责？ 来源：https://pointieststick.com/2026/07/19/whos-responsible-for-bug-reports-on-old-software-versions/ 设想一个场景： 某操作系统 \(OS\) 内置了某软件的 1.5 版本。 而该软件的最新版本是 3.0。 该操作系统的一位用户在使用 1.5 版本时遇到了问题，或者有了一个新功能点子。**他们该联系谁？** --- 这个场景之所以真实存在，是因为有*固定版本*操作系统，比如 Ubuntu、Debian、openSUSE Leap 和 Linux Mint。这些系统有意将所包含的某些软件版本冻结一段时间——即使上游已经发布了更新的版本。 这事儿最近上了新闻，正是因为 Linux Mint 发生了一场争执；一位 GNOME Calendar 的开发者要求 Linux Mint 移除支持链接并更改品牌标识（https://gitlab.com/linuxmint/pins/mint/gnome-calendar/-/work_items/1），随后在问题因合理原因被锁定后，又发了一篇相当煽动的博文（https://tesk.page/2026/07/18/how-far-would-hostile-distributions-go-to-hurt-upstream/）。 这让我感到遗憾，因为这种沟通不畅本可以避免，而现在围绕这个话题的讨论，有很大一部分都在争论语气，而不是话题本身——这是不注重语气的必然结果。扯远了。 --- 我觉得这是个重要话题，所以想分享一下我对这件事的看法。 ## 软件开发者有责任吗？ > *软件是开发者写的。软件出了问题。事情就是这样。* 要是生活真那么简单就好了！ 我曾收到过成千上万条关于固定版本操作系统中 KDE 旧版本软件的、无法处理的 bug 报告，这些问题早在数月或数年前就已经修复（但操作系统发行版没有反向移植！）……我可以告诉你，这非常令人沮丧。 但我们身处自由开源软件（FOSS）世界，我们的软件是通过自由软件许可证发布的；我们必须做好心理准备，操作系统可能会以我们未曾预料或不太满意的方式分发我们的软件，并且会收到来自其用户的 bug 报告。这就是现实。 我们在 KDE 的解决方案是：用一个机器人自动关闭那些针对已停止支持版本的 bug 报告。我们最终可能还会把这个机制扩展到我们的应用程序和框架。 这并不完美，但基本能行得通。我之所以知道，是因为现在我看到的大多数 Plasma 新 bug 报告都来自使用滚动发布操作系统（如 Arch、OpenSUSE Tumbleweed 和 Fedora KDE（虽不是严格滚动，但也差不多））的用户，而且大多数都是可处理的。 这对固定版本操作系统的用户来说有点糟糕，他们辛辛苦苦提交了 bug 报告，结果却收到一个机器人的回复，告诉他们这报告没用。但他们也受益于滚动发布用户实际上充当了他们的免费质量保证（QA）。这算是一种权衡。 ## 发行版（分发商）有责任吗？ > *如果我的车坏了，我会怪汽车公司——而不是卖给他们那个坏零件的供应商。* （嗯，如果我是个汽车迷，我可能也会怪供应商，但那是例外！） 归根结底，操作系统发行版就像是这里的汽车公司，负责组装最终产品。他们的工作应该是做好足够的 QA，并与供应商（上游软件开发者）合作，确保最终产品尽善尽美。 当然，一辆新车要花好几个月的工资，并且包含多年的保修期，而大多数 FOSS 操作系统不收费，是免费分发的。所以期望值需要稍微降低一些。 我认为这就是沟通出现问题的地方。很多免费的 FOSS 操作系统在宣传自己时说得天花乱坠，承诺得天花乱坠。而实际情况是，很多系统只是由一个小团队，用极少的预算（甚至没有预算），从那些和开发者关系不太好的、脾气暴躁的开发者的多年旧软件组装而成。 用户因此并不清楚谁该负责什么，也不清楚他们应该期望从谁那里得到什么样的支持。 这就是为什么 KDE Linux 在其营销材料中包含了大量的限制条件和免责声明（https://linux.kde.org/）。我们不想过度承诺！这是一个由小团队建设的小项目。我认为每款自由软件都应该明确说明谁应该使用它……以及谁不应该使用它。**不要过度承诺！** 这只会让所有人感到沮丧和失望。 如果你想要一个有专业支持的操作系统，**你可能需要为此付费**（https://pointieststick.com/2026/05/23/long-term-support-doesnt-mean-what-you-think）。 --- ## 那么解决方案是什么？ 作为一个发行版，我认为你需要确定你想与所包含的上游软件开发者建立什么样的关系。 你希望保持一种疏远的关系吗？**那我建议放弃固定版本发布，采用*滚动发布*方式。** 在这种模式下，你在上游软件发布的那一刻（或者至少很快之后）就将其纳入。这样冲突就消失了！几乎所有的 bug 都成为上游的 bug，你可以将用户引导至上游开发者，而不会遭到他们的反对。剩下的问题都是你可以自己修复的 OS 层面的问题。 当然，滚动发布操作系统仍可以与其上游保持良好的关系，但这并不是必需的。 不想做滚动发布？也没问题。**那么你需要与上游紧密合作。** 将用户的投诉和 bug 传达给上游，帮助推动修复，然后将其纳入。许多软件开发者除了发布功能版本外，也会发布 bug 修复版本。如果他们发布了……就纳入吧！不要忽视它们；这会让你的上游更加恼火。 如果任何上游发布了他们软件的“长期支持”版本（https://pointieststick.com/2026/05/23/long-term-support-doesnt-mean-what-you-think/），就使用那个版本。如果没有，你甚至可以与他们合作创建一个（如果他们接受这个想法），并帮助支持它。 这显然需要更多的工作。所以如果你的团队很小，可能无法对你包含的*每一个*软件都这样做。但你可以针对最重要的那些尝试：Linux 内核（https://kernel.org/）、systemd（https://systemd.io/）、Mesa（https://mesa3d.org/）、Libinput（https://wayland.freedesktop.org/libinput/doc/latest/index.html）、PipeWire（https://www.pipewire.org/）、NetworkManager（https://networkmanager.dev/）、BlueZ（https://github.com/bluez/bluez）、udisks（https://storaged.org/udisks/）、CUPS（https://openprinting.github.io/cups）以及 KDE（https://kde.org/）或 GNOME（https://www.gnome.org/）。 但这正是一个关键点：制作一个高质量的固定版本操作系统比制作一个优秀的滚动发布操作系统要*更*费力气。这是绕不过去的。 所以，让这种方法更可行的一个方式是**缩小操作系统的关注范围。** 例如，你可以将应用分发委托给第三方，比如 Flathub（https://flathub.org/）、Snap 商店（https://snapcraft.io/store）、AppImageHub（https://www.appimagehub.com/）等。这样你就可以只专注于基础操作系统及其桌面环境，而应用则是滚动的，这意味着它们会接受关于这些应用的 bug 报告。就我个人而言，我认为这种模式有很多可取之处。 另外，如果**不让软件变得*太*过时**，也会有帮助。最多半年？你的上游很可能可以接受，并且会接受 bug 报告。一年？基本没问题。两年？如果用户还在向上游报告 bug，那对上游开发者来说就开始变得痛苦了。三年或更久？非常痛苦。我们基本上只能让他们去找发行版商。 ## 什么不是解决方案？ 尽可能多地打包 2 年以上的上游软件冻结版本，然后忽视上游、忽视他们的 bug 修复版本、忽视他们的抱怨。 这是最糟糕的情况！ - 用户得到的是过时的软件，充满早已修复的 bug 和安全漏洞 - 软件开发者收到来自愤怒和困惑用户的、无法处理的 bug 报告 - 发行版收到软件开发者的负面反馈，损害或破坏了重要的关系 请不要这样做。这不可持续，而且会导致那些积极选择使用你操作系统的、最受欢迎的用户流失。 我怎么知道的？ 嗯，我不确定，但我可以根据我们已有的少数统计数据做出合理的猜测。一个重要数据是BoilingSteam 整理的 ProtonDB 上操作系统市场份额（https://boilingsteam.com/cachy-os-is-now-the-most-popular-distro-on-proton-db/），它统计的是 Linux 游戏玩家： [](https://pointieststick.com/wp-content/uploads/2026/07/image.png)2019年，“滚动及近似滚动（例如 Fedora）”操作系统占总用户的**36%**多一点。 到了2026年，这个比例上升到了**71%**。 当然，这不是全部用户，只是使用 ProtonDB 的游戏玩家。但这仍然是一个相当大的变化。很明显，游戏玩家认为滚动发布操作系统比固定版本操作系统更能满足他们的需求。 所以，如果你发布的是固定版本操作系统，并且不想或者不能切换到滚动或半滚动发布节奏，**请务必务必与你的上游合作！** 作为一个（遗憾的是现在只是偶尔活跃的）上游 KDE 软件开发者，我可以告诉你，我最喜欢合作的那些发行版，是那些与 KDE 互动并帮助解决问题的。当所有各方都专注于解决问题时，会非常愉快。