project-management - 你如何处理 Bugzilla 中的相关错误？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

2年前关闭。




Improve this question




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

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

到目前为止，我最好的想法是使用评论/描述，包括作品“与错误相关”，因为看起来“错误”这个词神奇地成为了指定错误的链接，从而可以轻松获得其他错误的详细信息。然后可以通过“评论包含搜索”条件进行搜索。

其他人如何做到这一点？

Answer 1

如果在您的 Bugzilla 中启用了depends/blocks 字段，我会使用以下工作流程，大致如下:

提交了客户特定产品中的错误 X；

如果发现它存在于核心产品中，则该错误的另一个“核心”版本(错误 Y)被归档到核心产品中，并用于阻止特定于客户端的错误(Y 阻止 X，X 取决于是);

核心团队继续修复核心错误Y；

当核心错误被修复时，客户端特定的错误 X 也可以被修复(它可能需要也可能不需要额外的努力)。

在评论中使用依赖/块而不是链接的好处是:

通知:当有人修改bug Y时，所有正在观看bug X的人也会收到通知；

强制措施:可以调整 Bugzilla 以禁止关闭依赖于至少一个打开的错误的错误，因此必须在关闭 X 之前关闭 Y。

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