Bug 报告指南
在 Arch Linux GitLab 上的 Bug tracker 中报告（和关闭）Bug 报告是帮助社区的众多方式之一。然而，格式不佳的 Bug 报告可能适得其反。当 Bug 被错误报告时，开发人员会浪费时间调查和关闭无效报告。本文档将指导任何想通过高效报告和追踪 Bug 来帮助社区的人。
另请参阅： Simon Tatham 的《如何有效地报告 Bug》
报告前
准备详细且格式良好的 Bug 报告并不难，但需要报告者的努力。报告 Bug 前所做的工作可以说是这份工作最有价值的部分。不幸的是，很少有人花时间来做好这项工作。
以下步骤将指导您准备 Bug 报告或功能请求。
搜索重复报告
如果您遇到问题或想要一个新功能，很可能其他人已经遇到过这个问题或有过这个想法。如果是这样，可能已经存在相应的 Bug 报告。在这种情况下，请不要创建重复报告；而是参阅 #跟进 Bug。
彻底搜索现有信息，包括
- Arch Linux 论坛：用户在寻求帮助或分享想法时，论坛通常是首站。虽然可能尚未找到解决方案，但额外的背景信息和讨论可能会指引您找到正确的方向。
- Arch Linux Bug Tracker：您的问题可能已经报告给 Arch Linux 开发人员。重复的 Bug 报告无益且会被立即关闭。请搜索已关闭和已打开的 Bug，方法是在“高级”选项中选择“所有状态”。请记住在“高级”下勾选“搜索详情”和/或“搜索评论”，因为 Bug 标题可能不包含您要搜索的文本。
- Google 或您喜欢的搜索引擎：使用程序的名称、版本以及错误消息的相关部分（如果存在）进行搜索。
- 上游论坛、邮件列表和 Bug Tracker：如果 Arch Linux 不负责某个 Bug，则应将其报告给上游，而不是 Arch Linux Bug Tracker。搜索最近关闭和已打开的 Bug 报告。Bug 可能已经在程序的开发版本中修复。
- 其他发行版的论坛：自由软件社区非常庞大；Arch 用户并非唯一有想法的人！例如，可以考虑搜索 Gentoo 论坛、FedoraForum.org 和 Ubuntu 论坛。
上游还是 Arch？
Arch Linux 是一个 GNU/Linux *发行版*。Arch 开发人员和软件包维护者负责编译、打包和分发各种来源的软件。上游指的是这些*来源*——在 Arch Linux 中分发的软件的原始作者或维护者。例如，流行的 Firefox 网页浏览器是由 Mozilla 项目开发的。
如果 Arch 不对某个 Bug 负责，那么将 Bug 报告给 Arch 开发人员将无法解决问题。当 Bug 不是由于发行版的移植和集成工作引起的，则说 Bug 的责任在上游。
通过向上游报告 Bug，您不仅可以帮助 Arch 用户和开发人员，还可以帮助自由软件社区中的其他人，因为解决方案会传播到所有发行版。
一旦您向上游报告了 Bug 或找到了上游的其他相关信息，将其发布到 Arch Bug Tracker 中可能会有所帮助，以便 Arch 开发人员和用户都能意识到它。
那么 Arch Linux 负责什么？
- Arch Linux 项目：pacman、AUR、mkinitcpio、Arch 网站。如果您不确定某个项目是否属于 Arch，请显示软件包信息（
pacman -Qi package_name或使用网站）并查看上游 URL。 - 打包：打包基本上包括从上游获取源代码，使用相关选项进行编译，确保它能在 Arch 系统上正确安装，并检查主要功能是否正常工作。Arch 的打包不包括添加新功能或对现有 Bug 进行修补；这是上游开发者的工作。
如果 Bug/功能不属于 Arch 的责任，请将其报告给上游。另请参阅 #不是 Bug 的理由。
Bug 还是功能？
- bug
- 应该工作但与开发者意图不符的东西。
- feature
- 软件能做什么，或者如果有人编写了代码会做什么。
不是 Bug 的理由
- 您希望某个软件执行但未被上游开发者实现的功能。简而言之：新功能。
- 一个已向上游报告的 Bug。
- 一个已向上游修复但在 Arch 中未更新的 Bug，因为软件包未及时更新。
- 一个未及时更新的软件包。请使用 Arch 的软件包网站上的标记软件包过时功能。
- 一个未使用 Fedora、Ubuntu 或其他社区补丁的软件包。补丁应提交给*上游*。
- 一个软件包中*非必要功能* X 或功能 Y 未启用的情况。这是一个功能请求。
- 一个软件包未包含*`.desktop` 文件*或*图标*或其他 freedesktop 相关文件。如果源代码压缩包中不包含此类文件，则这并非 Bug，并且必须*向上游*请求将其作为功能请求。如果*上游*提供了此类文件但软件包未将其使用，那么这是一个 Bug。
不是功能的理由
- 当它是 Bug 时...
- 当 Arch 不负责实现该功能时，即*上游功能*。
- 一个软件包未及时更新。请使用 Arch 的软件包网站上的标记软件包过时功能。
- 一个未使用 Fedora、Ubuntu 或其他社区补丁的软件包。补丁应提交给*上游*。
收集有用信息
以下是您的 Bug 报告中应包含的有用信息列表
- 正在使用的软件包版本。始终注明软件包版本。“最新”、“今天的”或“extra 仓库中的软件包”毫无意义。尤其是在 Bug 无法立即修复的情况下。
- 软件包使用的主要库的版本（在 `PKGBUILD` 的 `depends` 变量中可用），当它们与问题相关时。如果您不确定提供哪些信息，请等待 Bug 追踪者向您索取...
- 如果您遇到硬件相关问题，请提供使用的内核版本。
- 注明*功能曾经有效但现在无效*。如果曾经有效，请注明失效的时间。
- 如果您遇到硬件相关问题，请提供*硬件品牌*。
- 提供*相关的日志信息*（如果可用）。根据问题，可以从以下位置获取
- The systemd journal。如果使用 syslog-ng，` /var/log/messages` 包含与内核和硬件相关的日志。
- 如果遇到视频相关问题（nvidia、ati、xorg...），请提供 `~/.local/share/xorg/Xorg.0.log` 或 `/var/log/Xorg.0.log` 或 `/var/log/Xorg.2.log` 或任何 Xorg 相关日志文件。
- 在*控制台*中运行您的程序，并使用*详细*和/或*调试*模式（如果可用，请参阅程序文档），并将输出复制到一个文件中。在终端中运行应用程序时，请确保相关信息以*英文*显示，以便许多人都能理解。这可以通过使用 `export LC_ALL=C.UTF-8` 来实现。例如，对于一个名为 *foobar* 的软件，您希望在运行时获得相关信息，并且 *foobar* 具有 `--verbose` 选项
$ export LC_ALL=C.UTF-8 $ foobar --verbose
这将仅影响当前终端，并在关闭终端时失效。
如果您需要粘贴大量文本，如 dmesg 或 Xorg 日志的输出，最好将其保存到您计算机上的一个文件中并附加到您的 Bug 报告中。总的来说，附加文件比使用 pastebin 提供相关信息更可取，因为 pastebin 的内容可能因链接过期或其他潜在问题而失效。*附加文件可确保提供的信息始终可用*。
- *注明如何重现 Bug*。这非常重要，它将帮助人们在自己的计算机上测试 Bug 和潜在的补丁。
- 堆栈跟踪。这是程序在执行过程中调用的列表，有助于找到 Bug 所在的代码部分，尤其是在程序崩溃时。您可以使用 gdb（GNU Debugger）获取堆栈跟踪，具体方法请参阅 Debugging/Getting traces#Getting the trace。
报告 Bug
当您确定这是一个 Bug 或功能，并且已经收集了所有有用信息后，您就可以准备报告 Bug 或功能请求了。
创建账号
您必须在 Arch 的 GitLab 上创建一个账户，该账户通过 Arch Linux SSO 进行登录管理。
在哪里报告 Bug
一旦您确定您的功能或 Bug 与 Arch 相关，而不是上游问题，您就需要将问题提交到正确的项目。最简单的方法是在 archlinux.org 的相应软件包页面上点击添加新 Bug。
您也可以通过 `devtools` 中的 `pkgctl` 命令到达正确的页面
$ pkgctl repo web pkgname
AUR 中的软件包问题不应在 Bug Tracker 中报告。AUR 允许您向软件包添加评论，您应该使用它向软件包维护者报告 Bug。
标题
请为您的 Bug/功能请求写一个简洁而描述性的标题。
以下是一些建议
- 不要将您的报告命名为“pkgname 在上次更新后损坏”——这缺乏描述性，而且“上次更新后”在 Arch 中没有意义。
- 不要在标题中写太多文字。过多的文字在报告列表中不可见。
严重程度
选择*关键*严重程度并不会帮助更快地解决 Bug。它只会使真正关键的问题不那么显眼，并且可能使负责您 Bug 的开发人员不太愿意修复它。
以下是严重程度的一般用法
- 关键 - 系统崩溃、严重启动失败（可能影响多人）、或核心/对外服务软件包中的可利用安全漏洞。
- 高 - 应用程序的主要功能不工作、不太关键的安全问题等。
- 中 - 非必要功能不工作、未遵守 UNIX 标准等。
- 低 - 可选功能（插件或编译选项激活的）不工作。
- 非常低 - 翻译或文档错误。一些不太重要但应在未来版本中注意的事项。
包含相关信息
这可能是 Bug 报告中最困难的部分之一。您需要从#收集有用信息部分选择要添加到 Bug 报告中的信息。这将取决于您的问题。如果您不知道应该提供哪些相关信息，请不要害羞：*提供的信息过多比不足要好*。
一份关于 Bug 报告的出色教程可以在 https://www.chiark.greenend.org.uk/~sgtatham/bugs.html 找到。
然而，开发人员或 Bug 追踪者会在需要时向您索取更多信息。幸运的是，在报告了几个 Bug 之后，您就会知道应该提供哪些信息了。
简短信息可以内联在您的 Bug 报告中，而*长信息（日志、屏幕截图等）应作为附件*。
跟进 Bug
不要认为报告 Bug 后工作就完成了!
开发人员或其他用户可能会向您索要更多详细信息，并给您一些潜在的修复方案供尝试。没有持续的反馈，Bug 就无法关闭，最终结果将是用户和开发人员的愤怒。
投票和关注
您可以通过在问题上使用表情符号反应来*投票*给您最关心的 Bug。反应数量会告诉开发人员有多少人受到该 Bug 的影响，而不会产生太多噪音。然而，这并不是解决 Bug 的有效方法。更重要的是，如果您不是原始报告者，请提供您所知道的关于该 Bug 的任何额外信息。
关注 Bug 很重要：当有新评论添加或 Bug 状态更改时，您会收到电子邮件。这可以通过右上角的“...”菜单切换通知开关来完成。如果您打开了一个问题或对其进行了评论，您将自动订阅更改。
回应额外信息请求
人们会花时间查看您的 Bug 报告并尝试帮助您。您需要继续帮助他们解决您的 Bug。不回应他们的问题将导致您的 Bug 未得到解决，并可能打击修复它的热情。
请花时间提供更多请求的信息，并尝试提出的解决方案.
如果您在几周或一个月内没有回应问题，开发人员或 Bug 追踪者将关闭您的 Bug。
新软件包版本发布时更新 Bug 报告
有时，一个 Bug 只存在于给定软件包的某些版本中，并且该 Bug 在新版本中已被修复。如果是这种情况，请在 Bug 报告评论中说明，并请求关闭该 Bug。
解决后关闭 Bug
有时人们报告了一个 Bug，但没有通知他们自己解决了这个问题，导致其他人寻找一个已经找到的解决方案。如果您找到了解决方案，请关闭该 Bug，并在 Bug 报告评论中提供解决方案。
Bug 状态
在生命周期中，一个 Bug 可能会经历几个状态
- 未确认 - 这是默认状态。您刚刚报告了它，没有人能够重现该问题，或确认它实际上是一个 Bug。
- 新建 - Bug 已确认，但尚未分配给负责相关软件的开发人员。当需要更多调查来确定哪个软件导致 Bug 时，通常会是这种情况。
- 已分配 - Bug 已分配给负责涉及 Bug 的软件的开发人员。这并不意味着该开发人员将是修复 Bug 的人。甚至不意味着开发人员会着手解决。这仅仅意味着该开发人员将负责 Bug 的生命周期，包括审查补丁（如果有）、发布修复以及在需要时关闭 Bug。直接联系开发人员并要求他们更快地修复是不明智的；他们肯定不喜欢这样。
- 研究中 - 有人在寻找解决方案。此状态*在 Arch 中很少使用*，原因如下。*研究中*状态可能会让人们认为他们不必关心 Bug 报告。但通常修复 Bug 需要一个人以上：有多位经验丰富的人参与 Bug 会有很大帮助。
- 等待回应和需要测试 - Bug 报告者被要求提供更多信息或尝试提出的解决方案，但他们尚未回复。这些状态*在 Arch 中很少使用*，但应该更频繁地使用。尽管如此，重要的是您*关注该 Bug*（参见 #投票和关注），因为开发人员或 Bug 追踪者通常会在评论中提问。
- 已请求关闭任务 - 这不是一个确切的状态，但您可能会发现某些 Bug 报告带有这样的通知。这表明有人请求关闭该 Bug。大多数情况下都会添加原因。由分配的开发人员决定是否接受关闭。
- 已关闭 - 要么这不是一个有效的 Bug（参见 #不是 Bug 的理由），要么已经找到并发布了解决方案。
The Bug Wranglers 负责分派 Bug 并与其负责的软件包的维护者一起设置 Bug 的状态。