Replacing Bugzilla with Tuleap

Bugzilla has served the Eclipse Community well for many years, easily scaling to serve the needs of over 500 open source projects, servicing a community of thousands of software developers generating half of a million issue reports over close to two decades (I’m taking some liberties with that last one: it’s been about 17 years). When I say “easily”, I mean that our world-class IT team has made it look easy.

While generally robust, Bugzilla isn’t sexy, and it’s missing some valuable features. I’m also a little concerned that the team responsible for maintaining Bugzilla doesn’t seem to have the resources necessary to move Bugzilla forward (though, I’ll admit that I have only limited insight).

I’ve been investigating Tuleap, which is billed as “software development and project management tool”, as a potential successor to Bugzilla. Any effort to make Tuleap a first-class service for Eclipse projects will include the deprecation and eventual retirement of Bugzilla. Much like our migration from CVS to Git, I expect that project teams will start slowly adopting the new technology. Much like that other migration, the pace will likely pick up quickly as project teams see the benefits being reaped by the earlier adopters. This is how it will have to be: with project teams migrating themselves completely off Bugzilla and into the new system.

The criteria for picking a Bugzilla successor is pretty straightforward. Any new issue tracking software we adopt must:

  1. be able to import our existing issue (bug) data;
  2. be open source;
  3. have a strong community behind it; and
  4. provide equivalent functionality to what Bugzilla provides today.

Tuleap can import existing Bugzilla data directly, so that’s a huge win. We’ve discussed potential for synchronising data across systems, but that’s a big and expensive challenge that I’d really like to avoid. Once a team decides to move to Tuleap, the data will be moved and they’ll be off. This is an important consideration for project teams that might be considering participating in the ongoing proof of concept: we do have a means of moving your existing data from Bugzilla to Tuleap, but currently don’t have a means of making the return trip should we decide to move in a different direction.

Requiring that the replacement be open source is, I think, obvious. All of our public-facing systems are open source today and this will continue into the future.  Tuleap is 100% open source.

Having a strong community is important and ties into the open source requirement. Replacing Bugzilla is going to be a massive undertaking and we need to have confidence that the replacement that we choose has some staying power. Tuleap appears to have some large enterprise organizations adopting the technology, which is encouraging. We’ll expect to contribute to the open source project, but we need to be part of a community that plans to contribute and continue to evolve the product.

I think that it would be a mistake to look for a feature-to-feature replacement for Bugzilla. If we’re going to make this change, then we need to do some dreaming. Having said that, with my experimentation so far, I believe that Tuleap provides most of the fundamental functionality that we require.

A small number of our projects have started to independently evaluate the potential to use Tuleap. I’m certainly not an expert, but I’ve engaged with both the Tuleap project itself and several the Eclipse projects testing Tuleap via Tuleap as a user, so I’m starting to get a pretty good feel for it. So far, my experience has shown that it’s a pretty awesome bit of software and the projects that are currently using it seem to be moving along nicely.

Tuleap is more than an issue tracker. What I think sells a lot of project teams on Tuleap is the ability to engage in a full Scrum or Kanban process, but Tuleap provides all sorts of other services, including a wiki, document management, Git hosting, Gerrit integration, and more. It is relatively easy for a project team to create additional Git repositories from directly within the Tuleap interface. There is a notion of a project landing page that likely overlaps (at least a little) with the PMI; it may be worth investigating integration options (I’m not particularly keen on project teams being required to manage multiple landing pages on different services).

Tuleap provides fine-grained permissions which would make it relatively easy to, for example, give a project lead the ability to grant access to non-committer triagers (I believe that our various policies permit this sort of thing).

It is possible to add custom fields into a project team’s bucket to capture information that may be specific to the project. My understanding, however, is that the user experience for this sort of administrative task is not as refined as the user-facing interface. Customisation can be templated, which may make it possible to share some set of common customisations. But customisation introduces a troubling problem: since the source and target may have different customisation, moving issues from one team’s bucket to another team’s bucket is not currently supported: moving issues must be easy (especially considering the number of bugs that are incorrectly opened against JDT). Tuleap also does not currently provide an easy means of marking duplicates. According to the project team, these important features just haven’t been implemented yet. I’ve opened an artifact to track the need requirement to easily move issues.

Unfortunately, I believe that the abilities to move an issue from one project team to another, and to quickly and easily mark duplicates are critical to our adoption and so are show stoppers for the moment.

I have been trying to think a bit outside of the box. One of the bigger drivers for the need to be able to move issues is that the JDT team is the target for any and every issue that comes up in any variant of an Eclipse IDE that includes Java development tools. Maybe we can use adoption of a new issue tracking system as an opportunity to help our users find the right place to report issues without having to navigate our project structure. That’s going to require a lot of thought and energy from the community as a whole.

I think that Tuleap has a lot of potential, but we’re not quite ready for widespread adoption by Eclipse projects. I’ve managed to identify two show stoppers, but they’re point-in-time problems that will be addressed. I believe that we’re setting up a BoF at EclipseCon Europe 2016; if you’re using Tuleap now, or are interested in being a part of the decision making process for widespread adoption, please attend that session (and, of course, please do feel free to connect with me one-on-one at the conference). Please also to interact with the projects currently using Tuleap and let me know if your project is interested in participating in the experiment.

Finally, please join the discussion on Bug 497333.

EclipseCon Europe 2016

This entry was posted in Community. Bookmark the permalink.

7 Responses to Replacing Bugzilla with Tuleap

  1. Gunnar says:

    My main concern with Tuleap is that it implements too much functionality, which increases the learning curve for people. You would think that successful, large projects require such functionality but projects like Jetty are very happy with a limited, focused feature set (GitHub Issues).

    The other thing I’m worried about that it also aims to address too many concerns. It comes with wikis, Git, etc. Nothing of this will be integrated at Eclipse. There will still be with an old MediaWiki installation. There will still be cgit, which allows some browsing but does not nearly advance as fast as other Git options (Eg. GitLab or GitHub). Same is true for Gerrit.

    And then what’s next? What happens if Tuleap fails as a business? Great, we have the source code but will there be maintainers? Are we growing another legacy then?

    It seams that the hosting infrastructure is falling behind and not nearly able catching up with the pace at which others hosting solutions are evolving and addressing current concerns around simplicity, beautifulness and efficiency.

    I believe we should really question if the infrastructure strategy of the past is still applicable to the future, i.e. does it make sense to “replace” system X with system Y or do we need a whole different approach?

    The current stack is a set of tools assembled together over the years. There has been some level of integration but it always has been manual and time consuming work. Updates of one component break things. And again, the whole stack – Bugzilla, cgit, Hudson, MediaWiki – feels dated and unable to keep up with the pace of other solutions.

    Quite a lot projects outsourced hosting to an external service. They only use the EF for community building and its governance model. So the question really is, should the EF keep focusing on trying building a compelling stack or should its focus switch to provide managed services around external hosting solutions?

    You want to use GitHub? Go do it!
    You want to use GitLab? We got you covered.
    You like Tuleap? Go sign up for their service.
    Oh you got Bitbucket? Yes, we support hosting with them.
    You want to sponsor payed Atlassian stack for your project? Do it!
    You like Gerrit? We can sign you up for GerritHub.

    The EF could partner with one or multiple providers. The result of such a business partnership could be a branded “default” solution for projects struggling with making a choice and/or features that allow sign-in with an EF account.

    The EF webmaster team can focus on tools/infrastructure to backup/restore/maintain data from any of those systems. Eventually, they would have scripts to migrate from X to Y.

    The internal stack could be downsized/stabilized and maintained for existing projects. Eventually it can be end-of-life’d.

    Yes, all this requires a change in strategy. But remember, when the EF started, the current strategy made total sense. There weren’t any good hosting solutions available for OSS projects. We also don’t know what’s going to be the cool aid – which *is* attracting developers – in a few years. I believe flexibility is key for the future strategy. The EF does not grow as much with existing projects as with new and if there is only one or maybe two hosting options (custom-legacy-EF-stack and GitHub), the EF might not just be attractive to people anymore.

  2. Pingback: Eclipse Weekly: Die Zukunft von Eclipse (Teil 2) und der Rücktritt von Paul Webster - JAXenter

  3. Gunnar, I’ll re-phrase the answer I already made in the bug ( as people might only see Wayne’s blog and not the ticket in bugzilla.

    > My main concern with Tuleap is that it implements too much functionality,
    > which increases the learning curve for people. You would think that
    > successful, large projects require such functionality but projects like
    > Jetty are very happy with a limited, focused feature set (GitHub Issues).

    Actually the design of Tuleap allows you to choose what you want/need on a per project basis. If one project need only a simple issue tracker, it won’t inherit a complex workflow from a default template. But if other, larger projects want to do full scrum and what not, it’s also possible.

    > The other thing I’m worried about that it also aims to address too many
    > concerns. It comes with wikis, Git, etc. Nothing of this will be integrated
    > at Eclipse.

    As of today, it’s on purpose and there is no overlap with any existing EF tools. Neither git nor wiki are activated. Tuleap is initially there for a good Agile methodology support (scum & kanban) and the discussion extended to find a place with Bugzilla (initially the question was how to use both of them).

    More important, there is absolutely no reason to phase out current wiki, git or whatever as they are already working well. Plus we can discuss what level of integration between all those tool would make EF contributors more efficient.

    > And then what’s next? What happens if Tuleap fails as a business? Great, we
    > have the source code but will there be maintainers? Are we growing another
    > legacy then?

    That would be sad and EF would not be alone but yeah, like for any opensource project, if all active maintainers are leaving it’s an issue. A good way to address this concern is to grow more maintainers.

    • Gunnar says:

      Manuel, I do understand your affiliation. You don’t need to sell Tuleap to me. I’m arguing for a different kind of change. That’s unrelated to “let’s replace Bugzilla with XYZ”.

      • No worries, It’s more targeted for future readers that might end-up here thanks to google looking for Tuleap info. I fully understand the paradigm shift you’re advocating for and it’s not my role to challenge or support it.

  4. Pingback: Java Web Weekly, Issue 144 | Baeldung

  5. I just blogged a proposal to address one of the show stopper you reported:

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s