6

在我们的环境中，我们有一个核心代码库，以及该代码库的几个特定于客户端的实现。当客户提出问题时，我们需要确定它是客户特定问题，还是核心代码库问题。

我们使用 bugzilla 来跟踪我们的错误，我们为核心代码库和客户端实现提供了一个 bugzilla 产品（因为他们已经定制了产品以增强功能）。当客户提出与核心代码库相关的错误时，我们需要在 2 个 bugzilla 产品（核心和客户端）中提出该错误，以便两个团队都知道这个问题。理想情况下，我们会将这些错误联系在一起，这样我们就不会浪费精力尝试两次修复它，并且让 2 位项目经理完全了解该问题的进展情况。

到目前为止，我最好的想法是使用评论/描述，包括作品“与 bug 相关”，因为 bug 似乎神奇地成为了指向指定 bug 的链接，从而可以轻松获取其他 bug 的详细信息。然后可以通过“评论包含搜索”标准进行搜索。

其他人如何做到这一点？

4

1 回答 1

7

如果在您的 Bugzilla 中启用了依赖/块字段，我将使用以下工作流程，大致如下：

  • 提交了客户特定产品中的错误 X；
  • 如果发现它存在于核心产品中，则在核心产品中归档此错误的另一个“核心”版本（错误 Y），并使其阻止特定于客户端的错误（Y 阻止 X，X 依赖于是）；
  • 核心团队继续修复核心错误 Y；
  • 当核心错误被修复时，客户端特定的错误 X 也可以被修复（它可能需要也可能不需要额外的努力）。

在注释中使用依赖/块而不是链接的好处是：

  • 通知：当有人更改 bug Y 时，所有关注 bug X 的人也会收到通知；
  • 强制措施：Bugzilla 可以调整为不允许关闭依赖于至少一个打开的错误的错误，因此必须在关闭 X 之前关闭 Y。

我们曾经有类似的设置，将一个核心产品和两个生产产品运送给客户。但是，我们有一个负责所有产品的团队，所以更简单。通常在生产产品中提交错误，之后我们要么在那里修复它，要么将其升级到核心产品，或者为其他生产产品制造重复的错误。每当有两个错误记录存在同一个问题时，它们就会与依赖/块相关联。

于 2009-09-28T13:27:40.727 回答