问题跟踪指南

本文档描述了处理UBports项目中新问题的标准流程。请不要与 :doc：编写好的bug报告指南</贡献/错误报告> 混淆。

Bug 会在哪里被跟踪？

Since our quality assurance depends heavily on the community, we try to track issues where the user would expect them, instead of separated by repository. This means, that issues of almost all components that are distributed as with the system-image are tracked in the Ubuntu Touch tracker. An exception of this are click-apps that can be updated independently through the OpenStore.

大多数其他存储库在本地跟踪问题。 如果您不确定资源库是否使用自己的跟踪器，请查阅README.md文件。 不在本地跟踪问题的存储库禁用了错误跟踪器。

此页面主要介绍了关于Ubuntu Touch跟踪器的信息，但大多数原则上也适用于其他项目。

注解

实用性要大于整洁度！例外情况可能适用，应在项目README.md文件中加以说明。

GitHub 项目

To increase transparency and communication, GitHub projects (Kanban-Boards) are used wherever practical. In case of github.com/ubports/ubuntu-touch, a single project is used for all issues. Projects support filtering by labels, so that only issues that belong to a specific team or affect a specific device can be viewed.

以下是标准列：

  • None (awaiting triage): The issue has been approved by a member of the QA team and is awaiting review from the responsible development team. if the issue is a bug, instructions to reproduce are included in the issue description. if the issue is a feature request, it has passed a primary sanity check by the qa-team but has not yet been accepted by the responsible development-team.
  • Accepted: The issue has been accepted by the responsible development-team. If the issue is a bugreport, the team has decided that it should be fixable and accepts the responsibility. If the issue is a feature request, the team thinks it should be implemented as described.
  • In Development ：补丁正在开发中。 通常意味着开发人员已被分配到该问题。
  • Quality Assurance ：补丁已完成并已通过初始测试。 质量检查小组现在将对其进行检查并提供反馈。 如果发现问题，问题将转回“已接受”。
  • Release Candidate ：该补丁已通过质量保证并准备发布。 如果系统映像中包含 Debian 软件包，该补丁将包含在 rc 频道的下一个 OTA 更新中，如果一切顺利，则将在稳定版频道的下一个版本中发布。
  • None (removed from the project) ：如果问题是开放的且标记为“需要帮助”，则需要社群贡献才能解决问题。 如果它关闭，这意味着或者在稳定频道上发布了一个补丁（对该问题的评论应链接到该补丁），或者该问题已被拒绝（标记为“wontfix”）。

标签

所有问题 - 甚至是已关闭的问题 - 都应该贴上标签以使用 GitHub 的全局过滤功能。比如 `这些都是 @ubports 内部标记为“增强功能”的所有问题<https://github.com/search?utf8=%E2%9C%93&q=is%3Aopen+org%3Aubports+label%3A%22feature+request%22&type=>`_。有关搜索和过滤的更多信息，请参阅 GitHub 帮助页面 以获取更多信息。

这里是存储库通常使用的标签列表。

  • needs confirmation：这个 bug 需要受影响用户的确认和进一步提供信息
  • bug: This issue is a confirmed bug. If it’s reproducible, reproduction steps are described.
  • opinion：这个问题需要进一步讨论。
  • enhancement：这个问题是功能请求。
  • question：这个问题是一个支持请求或一般问题。
  • invalid：这个问题无法得到确认或是在错误的跟踪器中报告的。
  • help wanted：这个问题已经被报告。请提供链接并关闭。
  • help wanted：这个问题已经准备好由社区开发者提供帮助。
  • good first issue：这个问题并不严重，可以被修复。它被保留给新的贡献者作为开始的地方。
  • wontfix： 这个问题没有修复的意义，因为它要么可能会被自行解决、要么需要太多精力、要么不可修复，或者因底层组件即将改变而不需要修复。

流程定义仍在进行中，它需要由各个团队来完成：

  • ** critical（devel）**：这个严重的问题只在``devel通道上阻塞了下一个rc图像的发布``这一情况中发生。
  • ** critical（rc）**：仅在devel通道和rc通道上发生的关键问题阻碍了下一个稳定版本的发布。 通常情况下，不能简单地移动到不同版本并且有权推迟发布的问题都标记为此。
  • **device: [DEVICE CODENAME] **：此问题仅影响指定的设备。
  • **team: [TEAM NAME] **：这个问题属于特定团队（hal，middleware，UI）的责任范围。

注解

如果在本地跟踪问题的存储库定义了它自己的标签，则应将其记录在README.md中。

里程碑

里程碑仅用于稳定的OTA释放。 通常，创建正在进行中的OTA和下一个OTA的里程碑。 一旦发布的工作开始（从开始日期起6周），ETA就会设置，但之后可以进行调整。 有关详细信息，请参阅：doc：release-schedule <release-schedule>。

申请人

为了使处理问题的人员变得透明，应该指派开发人员。 这也允许使用GitHub的全局过滤作为一种TODO列表。 例如，`这是在@ubports <https://github.com/search?utf8=%E2%9C%93&q=is%3Aopen+org%3Aubports+assignee%3Amariogrip&type=>`_中分配给mariogrip的所有内容。

鼓励开发人员保持他们的清单简短并更新他们的问题状态。

事例

Bug 生命周期

注解

同样的原则适用于功能请求。 唯一的区别是，使用标签**增强**而不是标签** bug **。 **需要确认**标签不适用于功能请求。

  • 一个 * 用户 *使用问题模板提交新错误。
  • The QA-Team adds the label needs confirmation and tries to work with the user to confirm the bug and add potentially missing information to the report. Once the report is complete a team-label will be added to the issue, the issue will be put on the awaiting-triage-list of the project and the label needs confirmation will be replaced with bug.
  • 受影响的* 团队 将对问题进行分类，并拒绝（标签* wontfix ，关闭并从项目中删除）或接受该问题。 团队决定他们是否会在内部解决问题（转到“接受”并指派一名团队成员）或等待社区开发人员接收它（标签**帮助想要，从项目板中删除， 提供有关如何解决问题的提示以及有关如何在必要时实施修复的更多详细信息。 对于非常难以解决的非关键问题，也可以添加标签**良好的第一期**。
  • Once a developer is assigned and starts working on the issue, it is moved to “In Development”. As soon as they have something to show for, the issue is closed and automatically moved to “Quality Assurance” for feedback from the QA team. If necessary, the developer will provide hints on how to test his patch in a comment on the issue.
  • The QA-Team tests the fix on all devices and provides feedback to the developer. If problems are found, the issue is re-opened and goes back to “Accepted”, else it’s moved to “Release Candidate” to be included in the next release.
  • 如果尚未完成，则会将问题添加到下一个 Milestone。 一旦 Milestones 发布，问题就会从项目板中删除。