如何跟踪 Bugzilla 中的版本?
我们正在将错误跟踪从非常旧的 Track 版本迁移到 Bugzilla,而我的 Advil 已经用完了。
我们有一个已经存在很长时间的遗留应用程序。 事实上,我们的版本管理已经经历了几次迭代,它在野外生成了许多不同的版本。 更糟糕的是,由于合同限制,并不总是能够将客户端升级到最新和最好的版本,因此我们必须在他们当前拥有的版本上进行分支、修复、测试和发布,从而产生另一个版本号。
最终结果是版本组合框长得可笑。 最后,出于各种原因,我们想要跟踪三个不同的版本信息: 发现错误的版本(版本)、我们计划修复该错误的版本(里程碑)以及最终修复该错误的版本(接受建议)。 事实上,这是我的问题......这实际上可能是多个数字,我们对其中一些客户进行了追溯修复(这种情况经常发生)。
这就是我需要你们集体智慧的地方:
您如何在 Bugzilla 中跟踪这些版本(发现的、计划的和多个修复的)?
最佳实践是什么关于链接版本和错误跟踪?
回答
似乎克隆每个版本的错误是一种很好的跟踪方式,因此目标版本始终在里程碑和修复版本中进行跟踪,而有错误的版本是始终是本机版本。
此外,让每个克隆都阻止原始错误,使其成为将历史记录追溯到原始提交的好方法。
虽然我已经接受了答案,但我仍然欢迎您的意见。
We are in the process of migrating our bug tracking to Bugzilla from a really old version of track and I am running out of Advil.
We have a legacy application that has been around for a long time. Mix in the fact that our versioning management has been through a few iterations it generated a lot of different versions in the wild. To make matters worse, because of contractual limitations it is not always possible to upgrade the clients to the latest and greatest, so we must branch, fix, test and release, on the version they currently have, yielding yet another version number.
The end result is that the version combo box is ludicrously long. Lastly, for various reasons, we want to track three different version information :
the version in which the bug was found (version), the version in which we plan to fix (milestone) the bug and the version in which it has ultimately been fixed (open to suggestions). here is my problem in fact... this can actually be multiple numbers where we did a retroactive fix for some of these customers (this happens VERY often).
This is where I need your collective wisdom :
How do you keep track of these versions (found, planned and multiple fixed) in Bugzilla?
What are the best practices around linking versions and bug tracking ?
Answers
It seems that cloning the bug for each version is a good way to track, thus the target version is always tracked in the milestone as well as the fixed version, and the buggy version is always the native version.
Also to have each clone block the original bug make it a good way to trace the history back to the original submission.
Although I have accepted the answer I still welcome your input.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
![扫码二维码加入Web技术交流群](/public/img/jiaqun_03.jpg)
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
通常,如果我们需要修复多个发布版本(通常是源代码存储库中的分支)中的某些内容,则会为每个分支克隆错误,以便可以单独跟踪所有提交和发布状态。 我认为我们不这样做的唯一一次是当更改与代码库本身没有直接关系并且不能简单地通过更新我们的库来修复时。
至于一般的版本跟踪,我觉得这是一种合理的做法,因为我们通常只需要随时支持 2-3 个主要版本(加上主干)。 如果您有多个需要支持的不相交版本,例如特定于客户的部署,那么事情将更难以跟踪。 (可以说,这通常会引起头痛,最好将事物统一到更中心的版本主题)。
Often, if we need to fix something in multiple released versions (generally branches in the source code repository), the bug will be cloned for each branch so that all the commits and release status can be tracked separately. I think the only time we don't do this is when the change is not directly related to the codebase itself and cannot be fixed simply by updating our libraries.
As for version tracking in general, this has struck me as a reasonable way to do things, given that we generally only need to support 2-3 major versions (plus the trunk) at any time. If you have multiple disjoint versions that need supporting, e.g. customer-specific deployments, then things are going to be harder to track. (Arguably this is going to cause headaches in general and it would be better to unify things to a more central version theme).
我使用 Bugzilla 不仅可以跟踪错误,还可以跟踪新功能、增强功能和模糊的想法。 对于每个计划和发布的版本,我都有一个跟踪错误(我在原始 Mozilla bugzilla 上看到的东西,并发现它很有用)。
因此,如果您有错误报告,请输入错误及其所报告的版本号。 创建额外的错误(您计划修复的每个版本一个),这些错误都依赖于(阻止)原始错误并阻止特定于版本的跟踪错误。
如果阻止原始错误的所有错误都已关闭/验证(无论您的 QA 实现什么),您也可以关闭原始错误。
I use Bugzilla to keep track not only of bugs, but also of new features, enhancements, and vague ideas. For each planned and released version, I have a Tracking Bug (something that I saw on the original Mozilla bugzilla, and found to be useful).
So if you have a bug report, you enter the bug with the version number that it was reported. Create additional bugs (one for each version you plan to fix it in) which all depend on (block) the original bug and block the version-specific Tracking Bugs.
If all bugs blocking the original bug are closed/verified (whatever your QA implements), you can also close the original bug.
我一直在 TFS 中寻找类似的功能,在进行一些调查时,我发现 Bugzilla 中有一个管理“目击”的增强请求:
“Bug 55970 - (bz-branch) Bugzilla 需要更好地处理分支(实现目击)”:
https://bugzilla.mozilla.org/show_bug.cgi?id=55970
还有一个建议的设计:
https://bug55970.bugzilla.mozilla.org/attachment.cgi?id=546912
作为信息,我们将在 TFS 2010 中实现类似的功能,使用“Bug Parent”或“Bug Master”来保存有关 bug 本身的信息(重现步骤、严重性、技术信息、受影响的组件...... .),可以具有“Bug Child”或“Sighting”类型的子级,该子级将保存特定于给定分支的信息(目标里程碑、优先级、该分支的特定信息...)。
I was looking for a similar feature in TFS, and while doing some investigation, I found that there is an enhancement request to manage "sightings" in Bugzilla:
"Bug 55970 - (bz-branch) Bugzilla needs to deal better with branches (implement sightings)":
https://bugzilla.mozilla.org/show_bug.cgi?id=55970
There is also a proposed design:
https://bug55970.bugzilla.mozilla.org/attachment.cgi?id=546912
For information, we are going to implement something similar in TFS 2010, with a "Bug Parent" or "Bug Master" to hold the information about the bug itself (repro steps, severity, technical info, impacted components...), that can have child of type "Bug Child" or "Sighting" that will hold the information specific to a given branch (target milestone, priority, specific information for that branch...).
我们正在使用jira,但仍然有这个问题。 我认为这是一个需求以及如何使用版本的问题,而不是任何一种工具的问题。
谁使用版本以及他们如何使用它们?
版本与项目计划中的里程碑有何关系?
我们使用 4 dectet 版本 (major.minor.patch.buildNO)。 buildNo 是构建时的 SVN 头版本号。 每个版本都存储在 JIRA 中,问题有一个影响版本和一个多选的固定版本字段。
不久之后我们就有了很多版本。 Jira 确实允许我们通过两种方式控制列表
1. 存档版本(在选择列表中显示为灰色)
2. 合并版本(将多个版本合并为一个新版本 - 不可撤消)
我们使用了存档,但由于缺乏撤消功能而避免了合并。 所以我们仍然有很多版本的列表。
我确信您可以通过一些脚本和时间在 Bugzilla 中完成合并操作,问题是:什么时候可以将多个旧版本合并在一起?
如果我已经发布了,我是否需要知道我在启动和发布之间有 17 个版本? 我是否需要保留在构建 1 中发现的错误、在构建 2 中修复、在 7 中再次发现、在 9 中再次修复的信息? 或者 Found in release 1.0.0 是否已在 1.0.1 版本中修复?
今天晚些时候我将就这个主题提出一个大问题,但我已经知道基本答案:
- 取决于您的团队想要如何跟踪事物。
实施很有趣,但这一切都取决于需求、目标以及从用户体验到解决方案的工作。 当人们不一定知道如何使用那些不完全以他们想要使用的形式存在的东西时,这很粗糙。
We are using jira and still have this problem. I think it is a question of requirements and how are versions used rather than any one tool.
Who uses versions and how do they use them?
How are versions related to milestones in a project plan?
We use a 4 dectet version (major.minor.patch.buildNO). buildNo is the SVN head revision # at time of build. Each version is stored in JIRA and issues have an affects version and fixed-in version field that's a multi select.
After a short while we have many versions. Jira does allow us to control the list in two ways
1. Archive versions (greyed out from pick list)
2. Merge versions (rolls several versions together into a new version - no undo)
We have used Archive, but have avoided Merge due to the lack of the undo. So we still have a list of many many versions.
I'm sure you could probably accomplish a merge action in Bugzilla with some scripting and time, the question is: when is it OK to merge several older versions together?
If I have released, do I need to know that I have 17 builds between start and release? Do I need to keep the knowledge of a bug being found in build 1, fixed in 2, found again in 7, fixed again 9? Or is Found in release 1.0.0 fixed in release 1.0.1 good enough?
i'm going to ask a large question on this topic later on today, but I know the basic answer already:
- Depends on how your team wants to track things.
Implementation is fun, but it all comes down to requirements, goals and working back from user experience to solution. Which is rough when people don't necessarily know how that want to use something that doesn't quite exist in the form they'd like to use.
我创建了一个自定义字段(字符串)来列出已修复错误的版本(如 VMPB)。
我还创建了另一个自定义字段(字符串)来列出受错误影响的版本。
这样做您可以对特定版本执行快速搜索。
I have created a custom field (string) to list to version(s) (as V.M.P.B) where a bug has been fixed.
I have created also another custom field (string) to list to version(s) affected by a bug.
Doing that you are able to perform quick-search on specific version.