We don’t allow questions seeking recommendations for software libraries, tutorials, tools, books, or other off-site resources. You can edit the question so it can be answered with facts and citations.
Closed 9 years ago.
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(14)
在工作中,我们使用 FogBugz,在我看来,它是迄今为止同类工具中最好的工具。 我会将它用于我从事的非营利项目,但它对于超过 2 个用户来说太昂贵了。
对于非营利项目,我们使用 Lighthouse 进行问题跟踪。 就其价格而言,它还不错,坦白说,我在其价格范围内找不到任何合适的替代品。 Trac 的问题跟踪比 Bugzilla 好不了多少...我知道很多人喜欢 Trac,但我发现它非常不灵活。 Trac 的缺陷将我们引向了 Lighthouse。
我的非营利项目正在考虑迁移到 Bitbucket。 除了问题跟踪之外,它还可以让我们整合 beanstalkapp.com 上的存储库,并添加一个 wiki。
话虽如此,如果 FogBugz-on-Demand 的定价与针对小用户数量的 Lighthouse.app 稍有相似,我会毫不犹豫地将我们转移到那里。 当你在工作中使用 FB,然后在晚上使用 Lighthouse.app 时...使用 Lighthouse 感觉就像你的手臂被砍掉了。
At work we use FogBugz and it's by far the best tool of its type in my opinion. I would use it for the non-profit projects I work on, except it's so expensive beyond 2 users.
For the non-profit projects, we use Lighthouse for issue tracking. It's alright for what it costs, and frankly I can't really find any suitable alternatives within its price range. Trac's issue tracking is little better than Bugzilla's...I know a lot of folks love Trac but I find it very inflexible. Trac's deficiencies led us to Lighthouse.
My non-profit projects are looking possibly at moving to Bitbucket. In addition to the issue tracking, it would let us consolidate our repositories over there from beanstalkapp.com, as well as, adding a wiki.
That all being said, if FogBugz-on-Demand had pricing even remotely similar to Lighthouse.app for small user counts, I'd move us over there in a heartbeat. When you use FB at work and then Lighthouse.app at night...using Lighthouse feels like your arm has been chopped off.
Mingle 通过 mingle_git 插件。 Mingle 拥有针对开源项目的免费社区许可证 。
Mingle supports git via mingle_git plugin. Mingle has a free community license for open source projects.
我也将 github 与 Lighthouse 一起使用。 如果您的提交消息包含类似
[#32 state:resolved] 的
内容,Lighthouse 将根据提交解析票证 #32,我发现这快速且有用。 除此之外,Lighthouse 的功能有点,呃,很少。
I too use github with Lighthouse. And if your commit message contains something like
[#32 state:resolved]
Lighthouse will resolve ticket #32 against the commit, which I find quick and useful. Other than that, Lighthouse is a bit, er, light on features.
我建议 JavaForge 作为替代方案,因为它拥有您想要的一切:
请注意,该网站由 codeBeamer 提供支持,这是我们经过全球测试的商业产品公司。
(免责声明:我们是敏捷 ALM 解决方案的商业提供商。)
I'd suggest JavaForge as an alternative, since it has everything you look for:
Please note that the site is powered by codeBeamer, our commercial product battle-tested by global companies.
(Disclaimer: we are a commercial provider of agile ALM solutions.)
我正在构建机场。<plug>
I'm building Airport.</plug>
您还可以尝试使用 BusyFlow 等工具。 您可以在其中跟踪 GitHub 提交并对它们发表评论(评论与 GitHub 同步)。 对于其他项目管理方面,BusyFlow 与 Google Calendar、Trello、Basecamp、Pivotal Tracker 等集成。因此您可以查看 GitHub 项目以及任务、文件和日历事件。
(免责声明:我是 BusyFlow 的联合创始人。)
You could also try using a tool like BusyFlow. There you can track GitHub commits and comment on them (the comments are synced with GitHub). For other project management facets BusyFlow integrates with Google Calendar, Trello, Basecamp, Pivotal Tracker etc. So you can see your GitHub items alongside with tasks, files and calendar events.
(Disclaimer: I'm a co-founder of BusyFlow.)
您考虑过 CodePlex 吗?
Have you considered CodePlex?
如果您认为自己真的会成为唯一的开发人员,Fogbugz 将为您提供帮助你保持理智。 Fogbugz 是一个很棒的产品,它建立了有针对性的沟通,并且可以将任何事情变成案例(问题)。 它可以像我见过的任何系统一样完成所有这些工作。
但它的定位是商业性的——用户和技术支持之间的高效沟通,提高日程安排的可靠性,重点和技术支持。 优先考虑正在开展的工作,将内部和外部分开。 外部讨论,一些很好的报告来跟踪事情的处理情况。 (我能想到的唯一批评是它没有进行案例阻塞和依赖项跟踪,这对于那些埋藏很深的错误非常有用。)
这个功能集几乎不会帮助您构建一个活跃的开源项目,并且具有开放的活力沟通和需求建立了一个社区,并随着项目的发展让用户发展成为开发人员。 因此,如果这就是您想要的结果,您可能真的想要这些轻量级跟踪系统之一的不太集中的通信渠道。
我还没有在项目中使用过 Google Code,但是就透明性而言 开放式沟通,看起来像是对活跃的开源项目的良好支持。 而且你已经知道了。 如果您想增加对项目的参与度,Google 代码似乎是您的最佳选择。
If you're thinking that you'll really be the only developer, Fogbugz will help you keep your sanity. Fogbugz is a great product, It builds focused communications and can turn anything into a case (issue). It does all that as well as any system I've seen.
But its orientation is commercial -- efficient communication between users and tech support, improve reliability of schedules, focus & prioritize what's being worked on, separate internal & external discussions, some good reporting to track that things are getting handled. (About the only criticism I can think of is it doesn't do case blocking and dependency tracking, which is really useful for those bugs buried deep.)
Little of this feature set will help you build an active open source project, with open lively communication and the need build a community and have users evolve into developers as the project grows. So if that's where you want to end up, you may really want the less focused communication channels of one of these lightweight tracking systems.
I haven't used Google Code on a project yet, but in terms of transparent & open communication, it looks like a good support for an active open source project. Plus you already know it. If you want to grow the involvement in your project, Google code looks like the way to go.
GitHub 最近推出了自己的问题跟踪器; 不过,我还没有进行竞争分析来确定它如何与本线程中提到的其他选项相媲美。
GitHub recently introduced an issue tracker of their own; I haven't done a competitive analysis to determine how it measures up to other options mentioned on this thread, though.
我使用 GitHub 和 Lighthouse 进行问题跟踪。 与其他一些选项相比,它有点准系统,但同时,如果您只想要一个轻量级工具,而不必担心太多,那么它的效果非常好。 如果您愿意,它可以与 GitHub 集成,并且对于开源项目也是免费的。
I use GitHub along with Lighthouse for issue tracking. It's a little barebones compared to some of the other options, but at the same time it works very well if you just want a lightweight tool you don't have to worry too much about. It can integrate with GitHub if you want, and it's also free for open source projects.
像往常一样,当有人问这个问题时,我会提到 Redmine,就像我在 这个问题。 我知道这个问题已经有了“最佳答案”,但我认为值得一提。
As usual when someone ask this, I mention Redmine as I did in this question. I know the question has already its "best answer" but I think it is worth mentioning.
我们使用 bitbucket.org,它不是 GIT,而是 Mercurial* ,但它确实有每个分支的错误/问题跟踪等 我认为
将这些东西与您管理源代码的地方集成起来非常有用,以便在提交消息中交叉引用诸如问题号之类的东西。 或者包含代码修订号的问题的固定消息。 如果您选择像 Google 代码这样的单独的 BTS,您就会失去这个。 正如其他答案中提到的,Trac 非常擅长集成。
编辑:我应该说,对于我最广泛使用的开源项目,我们实际上有它:
我知道这听起来很疯狂,但我们从每项服务中挑选最好的部分。 令人惊讶的是,没有人抱怨。
*
无论如何,我认为这更好,但请不要攻击我。We use bitbucket.org, which is not GIT, it's Mercurial* , but it does have bug/issue tracking per branch etc.
I think it can be very useful to integrate these things with the place you manage your source code for cross-referencing things like issue-number in a commit message. Or Fixed message for an issue containing the code revision number. You would lose this if you chose a separate BTS like Google code. As mentioned in other answer, Trac is really good at the integration thing.
Edit: I should say that for my most widely used open source project, we do actually have it at:
And I know this sounds insane, but we pick and choose the best bits out of each service. And surprisingly no one complains.
*
which is better in my opinion anyway, but please don't flame me.您是否考虑过 Trac ?
似乎对 git-Trac 集成 进行了“热情”的评论。
我对这些工具没有个人经验,但您可能想查看一下集成。
Have you considered Trac ?
There seems to be an "enthusiastic" review of a git-Trac integration.
I have no personal experience with these tools but you may want to check out the integration.
我在某些地方使用 github 和 google code。 谷歌代码的问题跟踪器足够不错,但我无法处理颠覆。
请查看我的 java memcached 客户端 以获取相关示例 - 特别是源选项卡在顶部。
I use github and google code in some places. Google code's issue tracker is decent enough, but I can't deal with subversion.
Take a look at my java memcached client for an example of this -- particularly the source tab at the top.