本文是对 Firefox OS 项目提交 Bug 的指南， 包括 Gaia 和 B2G。
Bugzilla
与 Mozilla 中的大多数项目一样，我们用 Bugzilla 作为软件缺陷的追踪管理。当你发现程序错误时，你可以向 bugzilla 中的 Firefox OS 产品提交 bug 报告，其中包含 Gaia、Gonk 以及 Firefox OS Gecko 等组件。你可以从这里报告关于Firefox OS、B2G、Gaia 等组件的 bug。
注意： The Mozilla B2G QA Wiki page also has some useful resources on handling Firefox OS bugs; the most useful pages are Bugzilla Usage and Incoming bug triage for Firefox OS.
提交 Bug
你可以依照 bug 报告撰写指南中的内容来报告优秀的 bug，你也可以在下面发现更多的细节。
强制和可选字段
在报告新 bug 时，有一些必填域：
| 字段 | 描述 |
|---|---|
| 类别 | 选择这个bug所属的类型，如果你不清楚这个问题所属的类型，你可以将它放到"常规"问题当中。 |
| 概要 | 简要描述这个bug的概要。 |
| 描述 |
清楚地描述情况，一个好的bug报告应该包含有:1.重现的步骤(STR), 2.预期结果(程序本应该出现的结果)和实际结果(因为bug产生的结果), 3.顺便说明出现bug的频率(即:您多次重复这样的步骤后这个bug出现次数)。 |
| 版本信息 | 进入 设置>设备信息>更多信息 并且将下列信息与bug一并提交:操作系统版本，内部版本号，平台版本，构建标识，更新方式。(如果你有一台带安装了adb功能的运行Mac或者Linux的电脑，你可以直接运行这个脚本，并且黏贴这个脚本的输出结果到bug报告中)。 |
| 截图 | 请抓取一个截图方便我们分析这个bug。(在Flame设备上，可以同时按住电源键和音量下键两秒直至设备显示截屏通知，然后通过USB线传输到电脑上以便提交)。 |
| 录制视频 | 如果这个bug的截图不方便传输或者难以通过截图来捕获，请录制一段关于这个bug的视频，你可以将视频文件上传作为bug报告的附件，也可以上传至YouTube网站并且复制视频链接至报告中。 |
| ADB 运行日志 | 如果你的电脑安装了ADB工具，请将你的设备连接到电脑并且在ADB中运行以下命令|adb logcat|。请将这个命令的输出信息复制到一个文本文档中并且附到bug报告中。 |
以下是可选域：
| 字段 | 描述 |
|---|---|
| 依赖/块 | 列出多个bug之间的联系。 |
| 关键词 | 为bugzilla列出关键词. 特殊的团队将用它们来追踪。 |
| 白板 | 包含标签，为追踪bug添加标签，你不能未经许可就擦除其他的标签。 |
| 看点别的 | 有时候，两个问题是相互有关联的，你可以指定它们。 |
| 旗子 | 用于追踪的旗子; the most used flag in Firefox OS bugs is blocking-b2g. If a bug is set as blocking-b2g, it means we should pay more attention to it as it threatens to block a release. |
| Security | If a bug is related to personal data security, loss of earnings, and other such issues, you should check the checkbox and it will only be visiable to involved employees. |
To find more information on bugzilla fields, you can view the Bugzilla Fields page on Bugzilla.
常见关键字
下面的表格提供了你将在 Firefox OS 的 bug 报告中经常见到的关键字。
| 关键字 | 描述 |
|---|---|
| meta | Indicates that the bug is a status tracking bug. Mozilla uses this tag to tracking multiple bug or user story implementation statuses. Once marked like this, developers should not land patches on top of such bugs. Please be reminded that project managers and QA staff will use meta bugs for tracking. |
| qablocker | Use this keyword for bugs that are blocking testing (manual or automated testing of a feature) and need to be fixed by the next Beta or RC milestone. |
| qawanted | Use this keyword for bugs that need more info, require reproducing or testcasing, or are duplicates (but you can't find the original bug being duplicated). Required QA work progress is recorded in the whiteboard; you should remove this keyword when the required QA work has been completed. |
| regression | This keyword means that the problem was fixed, but then it came back (regressed) and the bug in question is a new bug, filed to track the regression. It can also refer to problems outside those identified in pre-check in and smoke tests, which were found in current builds and that were known to be working in previous builds. Tracking these bugs helps us to identify areas that are fragile, prone to breakage and are good candidates for adding to smoke and pre-check in tests. |
| regressionwindow-wanted | Indicates that the bug is a regression, and would strongly benefit from someone identifying the time period in which it happened, ideally to a specific check in. |
| steps-wanted | Highlights a bug that would greatly benefit from someone identifying the steps to reproduce it. |
| verifyme | Means that this bug is ok to verify with the latest B2G build by someone other than the QA Contact indicated. The bug has specific machine configuration details indicated for verifying the fix. You should try to reproduce the failure, and, if you agree that the resolution of Fixed is correct, mark the Status as Verified. You should always indicate the build/OS/platform(s) used to verify the bug in the bug comments, before you change the Status to Verified. If the bug is reported on all three platforms and you only have one platform to verify the fix on, go ahead and do so and note it in the bug, but do not mark the bug as Verified. All platforms must be checked before moving Status to Verified. Finally, if other bugs have been marked as a duplicate of the bug you're verifying, be sure to check and mention those as well. Often developers mark related — but not identical — bugs as duplicates, and these can be overlooked if not checked. |
注意：有关 Gaia 开发中对 bug 的处理的更多信息，请见向 Gaia 提交补丁。