apt-get debian 有好的 bug 追踪系统吗？

Question 1

我在上一份工作和目前的工作中都使用过 trac+svn。我不得不说，我发现这个设置太棒了！交叉引用票证（在 trac 中）和修订（在 svn 中）的方式非常引人注目。当接近部署时，我喜欢将每个提交与票证紧密联系起来，这样即使在较大的开发团队中也可以轻松跟踪更改。

在 Debian 上设置应该很容易使用 apt-get install。

trac 的一个替代品是 Mantis。我使用 Mantis 的次数远不及 Trac，但我肯定不太喜欢它。

编辑：据我记得，要设置 svn/trac 引用你需要做两件事：

在您的 svn 存储库上设置提交后挂钩。
编辑您的 trac.ini。

我认为这解释得很好这里，尽管文本可以更清晰一些。

这是我的设置：

在您的 svn 存储库上设置提交后钩子。以下内容来自我的 /path/to/svn/repos/myrepo/hooks/post-commit ：

REPOS="$1"
REV="$2"

TRAC_ENV="/path/to/trac/"
/usr/bin/python /usr/share/doc/packages/trac/contrib/trac-post-commit-hook -p "$TRAC_ENV" -r "$REV"

编辑你的 trac.ini。这是我添加到我的 ini 文件中的内容，我不记得它们周围的细节，所以你需要自己查找：

[trac]
....
repository_dir = /path/to/svn/repos/myrepo/
repository_type = svn
...

[svn]
branches = trunk,branches/*
tags = tags/*

[components]
trac.versioncontrol.svn_fs.subversionconnector = enabled

编辑 2：我所说的“保持紧密”实际上并不是由 svn 或 trac 强制执行的，这只是一种我认为非常有效的思维方式，至少在我的团队中是这样。我们从每个开发周期的开始到结束都使用 trac，并将所有请求的功能/错误修复/增强功能放入票证中。一旦开发出一个功能，开发人员就会将票证提交测试，当测试被批准（由 PL）时，票证就会关闭。然而，在正常周期中，有时开发人员会提交与任何票证无关的内容，这可能是一个小功能或一个没有人知道的错误修复，这时您有两个选择：要么放手（快速、简单），要么创建一个新的票证来绑定提交（缓慢、繁琐）。除非它是一个主要的新功能，否则我们通常会采用快速修复。

然而，在周期结束时，跟踪每次提交变得越来越重要，因为每次提交都可能破坏系统。因此，我发现强制（通过口头）每个开发人员在每次提交中写下与提交相关的票号 ID 非常有用。（如果您在注释中写下 #123 来提交给 svn，其中 123 是票号，您实际上可以在 trac 时间线中浏览它，太棒了！）

这有两个效果：1) 开发人员在提交之前会额外查看一次，这样每次提交中的所有内容都只与特定票证相关。2) 我更容易看到每次提交可以测试哪些功能/错误修复。例如，如果我想一次测试一个错误修复，我可以签出修订版本 123 来测试一个错误修复，签出修订版本 124 来测试另一个错误修复。

好吧，这篇文章开始变成一篇小文章了，我需要在这里停下来。我希望你明白我的意思。我想我的建议是制定你自己的、在开发小组中众所周知的指导方针，并在编写提交评论和新票时使用 #123（参考票证）和 r234（参考 svn 修订版）。

（例如，当您回复一张票时，您写“我在 r345 中修复了 XYZ。”，然后 r345 将成为 svn 树的链接，您可以准确地看到此修订版中更改了什么。

Answer