# Bug 报告流程

> **技巧**
>
> 提交 Bug 报告前，建议先发送到邮件列表咨询，以确认问题性质，避免重复报告，更有效地利用社区资源。

FreeBSD 缺陷报告系统位于 <https://bugs.freebsd.org/bugzilla>，提供缺陷跟踪与管理功能。

遇到问题时，建议按以下流程处理：

首先应确认问题并非用户自身操作或配置不当所致，可按以下步骤排查：

* 查阅常见问题列表、文档或手册等资料；
* 使用搜索引擎搜索相关信息；
* 搜索邮件列表，查看是否有人报告过类似问题；
* 在邮件列表中提问。

如果在刚升级的系统中遇到问题，请查看 **/usr/src/UPDATING** 文件的说明；如果是刚升级的第三方软件，请查看 **/usr/ports/UPDATING** 和 **/usr/ports/CHANGES** 文件。

相关文件结构：

```sh
/usr/
├── src/
│   └── UPDATING # 系统升级说明文件
├── ports/
│   ├── UPDATING # Ports 升级说明文件
│   └── CHANGES # Ports 变更记录文件
└── var/
    └── log/
        └── messages # 系统日志文件
```

判断该问题是否属于缺陷（bug）。如果问题可表述为疑问句（例如“如何操作……”、“何处可找到……”），建议先通过 FreeBSD 邮件列表咨询。

如果确认这是缺陷（bug），请核实系统版本是否仍受支持；不受支持的版本可能无人处理。

需要确认该缺陷（bug）是否已被修复：

* 检查系统版本，确认是否有更新和补丁；
* 搜索 FreeBSD bug 管理系统，确认是否有人报告过类似的问题。

如果没有人报告过类似问题，可以提交报告。

以下类型的问题不应提交：

* 某个应用已有新版本（通常会有自动通知告知维护者）；
* 对于无人维护的软件，如果没有补丁，仅报告缺陷可能无人处理；若有意维护该软件，请提交相关请求；
* 如果问题无法复现，他人也很难解决；
* 提出增加新功能的请求（可以在 FreeBSD 邮件列表中讨论，但建议先自行实现后再提交）。

确定应将问题报告给谁：

* 对于基本系统组件、文档或网站问题，请直接向 FreeBSD 开发者提交报告；
* 对于随系统发行但由他人维护的软件，除非能确定问题与系统无关，否则也请提交给 FreeBSD 开发者；
* 对于第三方软件，除非能确定问题与系统有关，否则请提交给软件开发者。

报告的书写提示：

* Summary 栏将作为邮件标题，请勿留空；
* “Summary”要有代表性，简明扼要；
* 如果有补丁，务必上传；
* 注明系统版本和计算机架构，如果是自行编译的软件，还需说明编译设置；
* 如果问题可以复现，注明问题产生的条件；
* 如果是内核问题，请准备以下信息：硬件配置、内核配置、是否开启调试选项、错误信息或 **/var/log/messages**，并声明已查看 **/usr/src/UPDATING** 但问题未解决（因常有人询问），以及是否可以运行其他内核；
* 如果是第三方软件问题，请准备好：安装的软件，所有覆盖 **bsd.port.mk** 默认设置的环境变量，声明已查阅 **/usr/ports/UPDATING** 但问题仍未解决（因常有人询问）；
* 每份报告应只包含一个问题，除非多个问题之间有紧密关联；
* 对有争议的问题应当谨慎，建议先进行讨论；
* 注意排版格式，尤其是在复制粘贴内容时；
* 请备份报告，以防网络状况不佳导致提交失败；
* 保持礼貌，报告的接收者大多是志愿者，请给予理解。

以下介绍 Bug 报告的填写方法：

请注意，邮件是公开的，可能会收到骚扰信息，请采取防护措施或使用公共邮箱。

* Summary：梗概，简明扼要；
* Severity：严重程度，只影响我/影响某些人/影响许多人，请勿过高估计严重程度；
* Category：类别，当前 Bugzilla 采用产品（Product）/组件（Component）两级结构，主要产品如下：
  * Base System：基本系统
    * kern（内核、库、内置驱动，手册 2-4），但 USB 子系统、多线程库除外
    * bin（内置程序）
    * conf（配置文件或启动脚本，man 5）
    * usb（USB 子系统）
    * threads（多线程库）
    * standards（标准遵循）
    * 某具体架构（与特定架构相关的）
    * misc（其他，或确实无法归类，建议先在邮件列表中询问）等；
  * Ports & Packages：第三方软件，其下主要组件为 Individual Port(s)；
  * Documentation：文档或网站；
* Environment（环境）：包括系统版本、程序版本、系统配置等；
* Description（问题描述）：内容应完整、详细，不要加入个人猜测。

FreeBSD 开发人员有限，缺陷报告可能长时间无人处理。报告接收者大多是志愿者，不应苛求。如果有可能，请先自行解决问题，再提交到上游。

> **技巧**
>
> [FreeBSD 的 GrimoireLab 监控面板](https://grimoire.freebsd.org/) 提供了 FreeBSD 项目目前的缺陷（bug）报告状态概览，展示项目开发活动与社区贡献的数据分析，可以直观地了解情况。

## 参考文献

* FreeBSD Project. Writing FreeBSD Problem Reports\[EB/OL]. \[2026-04-17]. <https://docs.freebsd.org/en/articles/problem-reports/>. FreeBSD 官方问题报告撰写指南，详细说明了 Bug 报告的提交流程与字段含义。

## 课后习题

1. 查找一个已提交的 FreeBSD 内核 Bug 报告，分析其包含的信息完整性，并复现其报告过程，尝试解决。
2. 重新设计一套本地化的行为准则。
3. 自由软件社区的行为准则（Code of Conduct）从最初反映自由软件激进平等主义逐渐演变为更温和包容的组织治理工具。比较 FreeBSD 社区当前 CoC 与 Linux 内核社区 CoC 在争议解决机制上的差异，并分析明确的行为准则是否确实提升了社区的贡献多样性。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://book.bsdcn.org/fu-lu-i-gong-ju-yu-zi-yuan/bug-bao-gao-liu-cheng.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.