It is relatively easy for a project team to create additional Git repositories from directly within the Tuleap interface. 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. 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. 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. Having said that, with my experimentation so far, I believe that Tuleap provides most of the fundamental functionality that we require.Ī small number of our projects have started to independently evaluate the potential to use Tuleap. If we’re going to make this change, then we need to do some dreaming. I think that it would be a mistake to look for a feature-to-feature replacement for Bugzilla. 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. Tuleap appears to have some large enterprise organizations adopting the technology, which is encouraging. 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. Having a strong community is important and ties into the open source requirement. 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. 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. Once a team decides to move to Tuleap, the data will be moved and they’ll be off. We’ve discussed potential for synchronising data across systems, but that’s a big and expensive challenge that I’d really like to avoid. Tuleap can import existing Bugzilla data directly, so that’s a huge win. provide equivalent functionality to what Bugzilla provides today.be able to import our existing issue (bug) data.Any new issue tracking software we adopt must: The criteria for picking a Bugzilla successor is pretty straightforward. This is how it will have to be: with project teams migrating themselves completely off Bugzilla and into the new system. Much like that other migration, the pace will likely pick up quickly as project teams see the benefits being reaped by the earlier adopters. Much like our migration from CVS to Git, I expect that project teams will start slowly adopting the new technology. Any effort to make Tuleap a first-class service for Eclipse projects will include the deprecation and eventual retirement of Bugzilla. I’ve been investigating Tuleap, which is billed as “software development and project management tool”, as a potential successor to Bugzilla. 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). While generally robust, Bugzilla isn’t sexy, and it’s missing some valuable features. When I say “easily”, I mean that our world-class IT team has made it look easy. 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).
0 Comments
Leave a Reply. |