用Tuleap替换Bugzilla

Bugzilla已经为Eclipse社区服务了很多年，可以轻松扩展以满足500多个开源项目的需求，为成千上万的软件开发人员提供服务，在近二十年中生成了一半的百万份问题报告（我正在考虑一些问题）。最后一个自由：已经有17年了。 当我说“轻松”时，我的意思是我们世界一流的IT团队让它看起来很容易。

虽然Bugzilla总体上很健壮，但它并不性感，并且缺少一些有价值的功能。 我也有点担心，负责维护Bugzilla的团队似乎没有必要的资源来推动Bugzilla前进（尽管，我承认我的见识有限）。

我一直在研究被称为“软件开发和项目管理工具”的Tuleap，作为Bugzilla的潜在继任者。 使Tuleap成为Eclipse项目的一流服务的任何努力将包括Bugzilla的弃用和最终退役。 就像我们从CVS迁移到Git一样，我希望项目团队将开始慢慢采用新技术。 就像其他迁移一样，随着项目团队看到早期采用者所收获的收益，这一步伐可能会很快加快。 这将是这样：项目团队将自己完全从Bugzilla迁移到新系统中。

选择Bugzilla继承者的标准非常简单。 我们采用的任何新问题跟踪软件都必须：

1. 能够导入我们现有的问题（错误）数据；
2. 开源；
3. 背后有强大的社区； 和
4. 提供与Bugzilla今天提供的功能相同的功能。

Tuleap可以直接导入现有的Bugzilla数据，因此是一个巨大的胜利。 我们已经讨论了跨系统同步数据的潜力，但这是我要避免的巨大且昂贵的挑战。 一旦团队决定迁移到Tuleap，数据将被移动并且它们将关闭。 对于可能正在考虑参与正在进行的概念验证的项目团队来说，这是一个重要的考虑因素：我们确实可以将您现有的数据从Bugzilla移至Tuleap，但是目前如果没有我们可以做的回程旅行决定朝另一个方向前进。

我认为，将替代品开源是显而易见的。 今天，我们所有面向公众的系统都是开源的，并将持续到未来。 Tuleap是100％开源的。

拥有一个强大的社区很重要，并且与开源要求紧密相关。 更换Bugzilla将是一项艰巨的任务，我们必须确信，我们选择的替代产品具有一定的持久力 。 Tuleap似乎有一些大型企业组织采用该技术，这令人鼓舞。 我们期望为开源项目做出贡献，但我们必须成为计划做出贡献并继续开发该产品的社区的一部分。

我认为为Bugzilla寻找功能到功能的替代品是错误的。 如果要进行此更改，那么我们需要做一些梦。 话虽如此，到目前为止，我一直在尝试，我相信Tuleap提供了我们所需的大多数基本功能。

我们的少数项目已开始独立评估使用Tuleap的潜力。 我当然不是专家，但是我既参与了Tuleap项目本身，又参与了几个Eclipse项目，它们通过用户的身份通过Tuleap测试了Tuleap，所以我开始对此颇有好感。 到目前为止，我的经验表明，这是一个很棒的软件，并且当前正在使用它的项目进展顺利。

Tuleap不仅是问题跟踪器。 我认为在Tuleap上出售许多项目团队的能力是参与完整的Scrum或看板流程的能力，但是Tuleap提供了各种其他服务，包括Wiki，文档管理，Git托管，Gerrit集成等等。 对于项目团队而言，直接在Tuleap界面内创建其他Git存储库相对容易。 有一个项目登录页面的概念可能与PMI重叠（至少一点）。 可能值得研究集成选项（我并不特别希望项目团队需要管理不同服务上的多个登录页面）。

Tuleap提供了细粒度的权限，例如，使项目负责人可以相对容易地授予非提交者分类程序访问权限（我相信我们的各种政策都允许这种事情）。

可以将自定义字段添加到项目团队的存储桶中，以捕获特定于项目的信息。 但是，我的理解是，这种管理任务的用户体验不如面向用户的界面那么精致。 可以对定制进行模板化，从而可以共享某些通用定制。 但是定制带来了一个麻烦的问题：由于源和目标可能具有不同的定制，因此当前不支持将问题从一个团队的存储桶移到另一个团队的存储桶：移动问题必须容易（尤其是考虑到针对JDT错误打开的错误数量） ）。 Tuleap目前还没有提供标记重复项的简便方法。 据项目团队称，这些重要功能尚未实现。 我打开了一个工件来跟踪轻松解决问题的需求。

不幸的是，我相信将问题从一个项目团队转移到另一个项目团队，以及快速，轻松地标记重复项目的能力对于我们的采用至关重要，因此，对于目前的示威者来说，也是至关重要的。

我一直在尝试跳出框框。 能够解决问题的更大推动力之一是，JDT团队是包含Java开发工具的Eclipse IDE的任何变体中出现的所有问题的目标。 也许我们可以利用采用新的问题跟踪系统作为契机，帮助我们的用户找到合适的位置来报告问题，而不必浏览我们的项目结构。 整个社区将需要大量的思想和精力。

我认为Tuleap具有很大的潜力，但我们还没有准备好被Eclipse项目广泛采用。 我已经设法确定了两个表演障碍，但是它们是可以解决的时间点问题。 我相信我们正在EclipseCon Europe 2016上设立BoF； 如果您现在正在使用Tuleap，或者有兴趣参与广泛采用的决策过程，请参加该会议（当然，请随时在会议上与我一对一联系）。 还请与当前使用Tuleap的项目进行交互，并让我知道您的项目是否有兴趣参加该实验。

最后，请加入有关Bug 497333的讨论。

翻译自: https://www.javacodegeeks.com/2016/09/replacing-bugzilla-tuleap.html