问题标签 [jira]

如何从 JIRA 中的 post 函数更新汇总字段的值？

任何人在 VM 上运行 Jira 有任何成功或失败吗？

我正在设置一个新的源代码控制和缺陷跟踪服务器。我的服务器机房快满了，我的服务组建议使用虚拟机。我看到一堆人在VM（包括NCSA）上运行SVN。VM 还可以让我摆脱硬件问题并为我提供高可用性。最后，它让我摆脱了一些繁文缛节，并且可以更快地实施。

那么，有人知道为什么我不应该将 Jira 放在 VM 上吗？

谢谢

有没有人幸运地从 jira 数据库中删除了大量问题而不是使用前端？使用 bulktools 删除 60000 个问题实际上并不可行。

上次我尝试它时，jira 因为它自己的索引方式而发疯了。

我使用的是标准版的 JIRA，总的来说，我喜欢它。但是，JIRA 似乎没有记录谁解决了问题、当前的受让人是谁以及谁报告了问题，这是一个常见的恼人来源。

因为没有记录“解决程序”，所以无法找到我解决的问题，或者我没有解决的问题（例如，在寻找要测试的问题时）。

某处是否有“打开”解析器跟踪的配置选项？

干杯，唐

Do you all add revision fixed to your custom fields?

And what is the point of have Work Start? I thought resolve issue is good enough?

目前我们有多个项目共享一个 JIRA 实例。我们想让用户只查看他们正在测试的项目。

但是，我们目前正在将这些用户分组到标准的 jira-users 分组中。

过滤掉只有特定用户才能看到和访问的 JIRA 项目的最佳方法是什么

我正在构建一些自定义工具来处理 JIRA 安装，并且公开的 SOAP API 很棒，除了没有命名任何参数。

例如，getIssue 的原型是：

所有的 SOAP RPC 方法都遵循这个约定，所以如果没有文档，我很难弄清楚要传递很多这些方法。

有人知道权威的 API 文档指南吗？

您如何跟踪更改、测试影响单独发布的多个工件的错误？

代码共享是好的，因为它减少了通过代码的路径总数，这意味着对更少的更改和更少的错误（或通过更少的更改解决更多错误）产生更大的影响。例如，我们可以构建使用相同文件处理包或模型包的搜索工具和索引器。

我们需要能够确保更改在所有正确的组件中得到测试，并跟踪哪些更改包含在哪些发布的工具中。我们也不希望被迫同时在所有应用程序中发布更改。

目标：一个要测试的错误，计划针对每个已发布的应用程序独立跟踪。借助了解架构的自动化系统，指导我们做出正确的选择。

漏洞拆分发布场景：

我们可能会发布一个搜索工具补丁，其中包含 util 库中的性能修复。对于搜索工具至关重要，修复在索引器中不太明显，因此它可以等到下一个维护版本。我们希望通过搜索补丁计划跟踪发布一个错误，并将其推迟到索引器的下一个维护版本。

因此，当我在我们的跟踪系统 (JIRA) 中创建错误时，我希望它神奇地变成多个对象。

• 描述问题和跟踪开发工作的主要问题
• 一组任务允许我跟踪测试工作，并让我跟踪这个问题是如何针对它影响的每个应用程序发布的。

我们如何才能使代码共享的用户体验变得更轻松，以鼓励更多的代码共享，而不会对哪些更改影响了哪些版本或迫使人们输入许多重复的错误视而不见？

我敢肯定，从 Eclipse 到 linux 发行版的大型项目都面临过这种问题，并且想知道他们是如何解决的（接下来我将讨论它们）。

你们有没有人遇到过这种情况，你们是如何处理的？

我们使用 JIRA 进行错误跟踪和发布管理，我们已经开始使用 greenhopper 在 JIRA 内部进行项目管理，但它缺少的一件事是用户故事与这些用户故事中的任务的概念。有没有人推荐其他任务板，例如完全支持用户故事和任务以及对用户快速简单的敏捷项目管理工具。我开始研究 targetprocess，所以如果有人对此有特别的反馈，那也很好。

如果有人试图做敏捷，我正在想办法为此使用 JIRA / Greenhopper。我们是一个全球开发团队，因此分布式特性在这里至关重要。

我们最初使用 Scrumworks，但团队抱怨他们在 JIRA 和 scrumworks 中一直有重复的信息，并认为这是多余的。

我们得到了 Greenhopper，并认为这可以解决我们的问题，但我遇到的问题是：

1. JIRA 中没有用户故事概念
2. Greenhopper 过于专注于“任务”而没有在用户故事级别进行聚合。

有没有人在 JIRA 中成功地做到了这一点，或者我们是否应该考虑回到其他工具，如 scrumworks，只使用 JIRA 来解决我们支持团队提出的错误。