Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse.org-architecture-council] Establishing our requirements for a Bugzilla replacement

Greetings Architecture Council.

I'm starting an evaluation of Tuleap [1] as a potential replacement for Bugzilla. I have several motivations for engaging in this effort, but two things stand out:

1) Bugzilla is not getting a lot of love these days. There are many large installations of Bugzilla, so I'm pretty confident that it will be around for the foreseeable future. It's not broken, probably won't be broken for a while, but isn't progressing either.

2) AFAICT Tuleap is well-regarded, is supported by some large organizations running large installations, provides some very useful features that Bugzilla can't touch, and is progressing.

To start the evaluation process, I'm gathering requirements. Here's where I'd like some help.

I'm thinking of this as a replacement activity: what must we have in order to completely replace our installation of Bugzilla with Tuleap? This will likely end up being a multiple-year process along the lines of what we did when we migrated from CVS to Git. At this point, we're in the early adopter stage where some projects are running their own instances. Determining the migration process comes later. For now, I'd just like gather the list of requirements.

What are the must-haves? Let's keep this high-level for now and try to focus only on those things that we need to have for a Bugzilla replacement (i.e. let's not add any requirements for features that we don't already have).

Here's my starting point:

1) Must be open source

2) Must integrate with existing EF infrastructure; i.e. run on our Linux version, leverage EF LDAP/OpenID, use MySQL as a backend, etc. (we need to enumerate this more completely)

3) Must provide equivalent to existing Bugzilla functionality (we need to enumerate this with some detail). e.g.

  • Must be able to accept issue reports from the community.
  • Must be able to restrict privileged access to lifecycle management to designated project committers.
  • Must be able to (easily) move tasks/issues/reports from one project/component to another
  • Must be able to accept issue reports from the community
  • Must be able to add comments, attach files, etc.

4) Must be able to migrate existing data from Bugzilla without significant loss of information (need to define "significant")

5) Eclipse Mylyn integration would be nice (or this is a must-have)?

Some of these are pretty obvious. The first one, "must be open source" has been added to answer the "why are you looking at Tuleap?" question. The short version is that the Eclipse Foundation has a policy that requires that all of our community-facing services be open source. Tuleap is the first viable open source solution for a Bugzilla replacement that we've encountered.

I'll admit that I'm a little excited by the prospect of using this change to stop using the term "bug" as a blanket for issue reports of all kinds. Though, I'll also admit that I really hate the use of the term "ticket" in this context. But I'll get used to it.

What am I missing?

I'd prefer that we have this discussion on Bug 498802 [2] (which I've set up as a blocker for bug 497333).

Thanks in advance,


Wayne


[1] https://www.tuleap.org/

[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=498802

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation

Back to the top