Closed. This question is opinion-based。它当前不接受答案。












想改善这个问题吗?更新问题,以便editing this post用事实和引用来回答。

去年关闭。



Improve this question





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

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

到目前为止,我最好的主意是使用包含“与虫子相关”的作品的注释/描述,因为“虫子”一词似乎神奇地成为了指向指定虫子的链接,从而使您可以轻松了解其他虫子的详细信息。然后可以通过“评论包含搜索”条件进行搜索。

别人怎么做?

最佳答案

如果在Bugzilla中启用了依赖/阻止字段,则将使用以下工作流,大致使用:


提交了特定于客户的产品中的错误X;
如果发现该错误存在于核心产品中,则该错误的另一个“核心”版本(错误Y)会提交到核心产品中,并用来阻止特定于客户端的错误(Y阻止X,X取决于Y);
核心团队着手解决核心错误Y;
修复核心错误后,也可以修复特定于客户的错误X(它可能需要也可能不需要额外的工作)。


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


通知:当某人更改错误Y时,所有正在查看错误X的人也会收到通知;
强制执行:可以将Bugzilla调整为禁止关闭至少依赖于一个打开的bug的bug,因此必须在关闭X之前关闭Y。


我们曾经有过类似的设置,只有一种核心产品和两种生产产品被交付给客户。但是,我们只有一个团队负责所有产品,因此更简单。通常在生产产品中记录一个错误,然后我们将其修复在那里,或将其升级为核心产品,或者为其他生产产品制作了重复的错误。每当有两个错误记录针对相同的问题时,它们就会与depends / blocks链接。

08-05 05:59
查看更多