openSUSE:KDE 缺陷筛选

KDE 缺陷报告筛选

通用

本页面旨在帮助处理在 openSUSE bugzilla 报告的关于 KDE 的缺陷报告。要报告缺陷报告，请访问 openSUSE:Bugreport_KDE（但如果您想帮助筛选，也应该阅读该页面）。

openSUSE 提供 KDE，包括测试和进行各种修改。然而，KDE 主要由 KDE 项目上游开发，虽然 openSUSE KDE 团队为 KDE 做出贡献，但由于资源有限（团队相对较小），他们无法处理每一个 KDE 问题。因此，保持报告给 openSUSE 的 KDE 缺陷报告的数量在 openSUSE KDE 团队能够处理的合理范围内非常重要。您可以通过筛选 KDE 缺陷报告来提供帮助。除了本页面和 openSUSE:Bugreport_KDE 页面提供的信息外，不需要任何特定知识，特别是，不需要成为开发人员。通过帮助处理缺陷报告，您可以减少 openSUSE KDE 开发人员花费在这些缺陷报告上的时间，使他们能够专注于改进 openSUSE 提供的 KDE。

本页面首先解释一些关于 openSUSE 的 KDE 缺陷报告的重要概念，然后提供一个分步指南，帮助您进行 bugzilla 筛选。

概念

bugzilla 中的缺陷报告组织

所有新的 openSUSE KDE 缺陷报告（即具有 KDE/KDE3/KDE4 组件的缺陷报告）最初分配给一个共享的 kde-maintainers@suse.de 别名，该别名由所有 openSUSE KDE 开发人员监控。初始筛选应在此处进行。

每个 openSUSE KDE 开发人员都有自己的个人 bugzilla 帐户，他们会将计划很快处理或属于其专业领域的缺陷报告重新分配到该帐户。然而，大多数缺陷报告仍然保留在共享的 kde-maintainers@suse.de 列表中。

您可以通过在“首选项->电子邮件首选项”中的列表中添加 bugzilla 帐户来监控任何 bugzilla 帐户，页面底部附近。要监控共享缺陷报告的变化，包括所有新的 KDE 缺陷报告，请添加 'kde-maintainers@suse.de'。

缺陷报告优先级

Novell bugzilla 中的缺陷报告使用优先级进行排序，以便更好地了解状态并使开发人员更容易看到他们应该按什么顺序处理缺陷报告。有一个专门的页面解释了优先级，请访问 openSUSE:Bug_definitions，请阅读它以了解应如何分配优先级。优先级主要由开发人员设置，但经验丰富的社区成员也可以通过设置优先级来提供帮助。开发人员仍然具有更高的优先级，因此请不要更改开发人员设置的优先级。此外，如果您还没有太多经验，请在设置优先级时小心。一开始不设置优先级，而仅在看到其他人如何设置优先级之后再开始设置会更安全。

上游 vs 下游

在此上下文中，上游是指 KDE 项目，其 KDE bugzilla 位于 http://bugs.kde.org。此处下游是指 openSUSE，其 Novell bugzilla 位于 http://bugzilla.opensuse.org。

Novell bugzilla 中 KDE 缺陷报告的基本规则是，只有 openSUSE 特定的或重要的问题才应报告并保留在那里。openSUSE 特定的意味着打包、应用程序、工具、桌面组件或由 openSUSE KDE 开发人员进行的修改，因为它们是 openSUSE KDE 开发人员的工作，它们不属于上游 bugzilla。在此上下文中，重要问题是指对 openSUSE KDE 桌面体验很重要并且可能影响许多用户或产生非常负面的影响的问题（从技术上讲，优先级为 P2 及以上的缺陷报告）。其他 KDE 缺陷报告应转发到上游 bugzilla，并在 Novell bugzilla 中关闭，状态为 RESOLVED UPSTREAM。

请参阅此页面，了解 openSUSE 进行的 KDE 修改列表。如果不确定缺陷报告是否是 openSUSE 特定的，请将其视为 openSUSE 特定的（并且可能稍后其他人会另作决定）。

仓库

这些规则主要适用于随 openSUSE 发行版一起提供的 KDE（包括在线更新）。对于通过其他仓库提供的 KDE，存在这些差异

KDE:Release:XY - 这用于准备最新稳定 openSUSE 发行版的次要版本更新和其他待处理的在线更新。因此，这些规则以相同的方式适用。
KDE:Distro:Factory - 此仓库提供将包含在下一个稳定 openSUSE 发行版中的 KDE。因此，它变得更加重要，仅在接近该发行版时，否则来自它的软件包的缺陷报告应更积极地转发到上游，因为上游有很高的机会会在发布时修复它们。
KDE:UNSTABLE:SC - 这是最新的不稳定 KDE。只有 openSUSE 特定的打包缺陷报告才应被接受。

通讯

您可以在 [主 KDE 页面] 中找到 openSUSE KDE 团队成员的联系方式。如果您对 bugzilla 筛选有任何疑问或问题，可以在那里向其他人询问。

缺陷报告状态

新的缺陷报告以 NEW 状态创建。缺陷报告应保持此状态，直到经过适当的分类并准备好由开发人员处理（或者关闭，当然）。当缺陷报告所需要做的就是开发人员修复它，并且从缺陷报告中清楚地了解问题是什么（如何重现它，等等），缺陷报告应设置为 ASSIGNED。

审查缺陷报告

在帮助处理缺陷报告时，请遵循以下准则

当报告一个新的缺陷报告时，首先检查它是否真的是关于 KDE 的缺陷报告。有时用户会将问题归因于 KDE，而实际上应该报告给例如 GNOME、X.Org、内核或其他发行版组件。如果缺陷报告应重新分配到另一个组件，请在 bugzilla 中更改“组件”字段并单击“提交”（重新分配将通过更改组件自动选择）。
检查缺陷报告的有效性和完整性:
- 不完整的缺陷报告 - 诸如“它已损坏”之类的缺陷报告，没有任何进一步的细节，完全没用。好的缺陷报告是能够清楚地了解发生了什么（可以看到如何重现）以及它的问题是什么（缺陷报告清楚地说明了问题）。一个不非常有用的缺陷报告的例子是只包含崩溃的反向跟踪，没有其他细节，特别是如果反向跟踪本身没有用（请参阅 openSUSE:Bugreport KDE#Useful_Crash_Reports）。此类缺陷报告应设置为 NEEDINFO，并向报告者询问缺失的信息。如果一个月后没有提供任何信息，请将旧的 NEEDINFO 缺陷报告关闭为 RESOLVED NORESPONSE，并附带“超过 4 周未回复。如果您能够提供所需的信息，请重新打开。”。如果报告者提供了信息，请确保删除 NEEDINFO 状态并再次审查缺陷报告。
- 无效的缺陷报告 - 有些缺陷报告可能会要求由于各种原因没有意义的事情（要求非常复杂和特定的功能，对事物的一般状态的随机抱怨而没有具体说明，等等）。此类缺陷报告应关闭为 RESOLVED INVALID 或 WONTFIX。
为缺陷报告分配优先级，如上所述。
检查是否可以重现该问题（如果例如太难并且没有时间，可以跳过，但此信息可能会有所帮助）
- 如果无法重现该问题，请考虑该缺陷报告不完整，并使用 NEEDINFO 询问更多信息。
- 如果无法在报告的版本中重现该问题，请使用评论说明，将 P3-P4 缺陷报告关闭为 RESOLVED FIXED。
- 否则，添加评论确认可以重现该问题，包括任何可能重要的信息。
决定是否应将缺陷报告保留在 Novell bugzilla 中或上游到 KDE bugzilla，使用以下准则（另请参见上文）
- 如果是 openSUSE 特定的问题，请保留它。
- 优先级为 P3-P4 且不是 openSUSE 特定的缺陷报告应转发到 KDE bugzilla，并关闭为 RESOLVED UPSTREAM。如果您可以在 KDE bugzilla 中找到相同的问题，请在关闭评论中提及该 bug 报告的 URL，并在“URL”字段中，否则自行报告该问题或要求报告者这样做。
- KDE:KDE4:Desktop:UNSTABLE 报告应仅在它是打包问题时保留，否则应 RESOLVED UPSTREAM。
- KDE:Distro:Factory 报告应更积极地进行上游处理，如果下一个稳定的 openSUSE 发行版即将发布。
- 其他缺陷报告应保留（即不是 openSUSE 特定的但足够重要，具有 P1-P2 优先级）。就像其他不是 openSUSE 特定的缺陷报告一样，它也应报告给上游 KDE bugzilla，因为上游通常更有可能首先修复该问题。
如果它准备好由开发人员修复，请将缺陷报告状态设置为 ASSIGNED。如果关于缺陷报告仍然存在不清楚的地方（无法重现，未确认问题存在等），请使用进一步的 NEEDINFO 或将其保留为 NEW，供其他人进行分类。
如果可能，将缺陷报告重新分配给其专业领域是开发人员，否则如果不知道或不确定，请将缺陷报告保留在 kde-maintainers@suse.de 别名中。大多数缺陷报告应共享，除非一位开发人员明确负责或有人想处理特定的缺陷。

标准回复

“感谢您提供的详细缺陷报告。我已将其转发给上游维护者 bugs.kde.org，我们将监控该缺陷以获取修复。如果可能，请将自己添加到上游 CC 列表中，以便您可以提供更多数据或测试修复。”