380493 - Bug API for integration between competing bug trackers

Status: NEW

(Bugzilla :: WebService, enhancement)

Description

[Stephanie Daugherty [:sdaugherty]]

As much as we'd wish otherwise, not everybody uses Bugzilla yet. There are other well established bug trackers, such as Mantis, Gnats, and Debian's BTS, not to mention Sourceforge's bug tracker, Trac, etc.

This is related closely to 123130, but not a duplicate, since 123130 deals only with integration between Bugzilla instances. This would likely depend on 123130 though, since the APIs can likely be reused.

I propose that a public API be created, with cooperation between competing products if we can get it, which will support dependancy relationships between seperate system, asd eventially, as much copy/move/forward functionality as we can manage in a compatable manner. 

For this to work right, the standard would have to specify a set of standard fields and values, to which each implementation would have to map it's own fields and values - for example, we use status and resolution fields that other products may not share, these should be mapped gracefully.between products - if a WONTFIX resolution exists in one, but the closest in another is "REJECTED" this this is how it should translate. 

So, basically, this boils down to:
- Creating a standarized object model for working with bugs, regardless of what bug tracking system holds them.
- Creating standard interfaces to that module.
- Exposing those interfaces as a web service.
- Using those interfaces to link to external bugs, regardless of what bug tracking system is used to hold them.

Comment 1

[Max Kanat-Alexander]

Yeah, I'd love to do this, but when I talked to other bug-trackers about a year ago about it, they didn't seem so interested.

But if you can get interest, I'd be willing.

There's already a standard Java API for Trouble Ticket systems, maybe we can work off of that.

Comment 2

[Steve Speicher]

I don't think this RESTful API supports all the scenarios that are described here but it is an evolving effort at OSLC: http://open-services.net/bin/view/Main/CmHome

As you can see from the site, there is already some implementations of this specification, including Tasktop/Mylyn, IBM, etc.   This effort is an open effort and participation in the development of the spec is welcome (as well as implementation of it).

Comment 3

[u336811]

(In reply to comment #1)
> 
> There's already a standard Java API for Trouble Ticket systems, maybe we can
> work off of that.

Any pointer ?

Comment 4

[u336811]

(In reply to comment #0)

> So, basically, this boils down to:
> - Creating a standarized object model for working with bugs, regardless of what
> bug tracking system holds them.

We're working on such a model, that we're currently trying to map to both Debian debbugs bugs and Bugzilla bugs (for a start), which is documented (slightly outdated maybe, as it's a work in progress) in https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web/HeliosBtOntology (done in collaboration with others on the baetle project).
We wish to demonstrate first bits of applications before the end of october, but feel free to contact me for a preview.

Hope this helps.

Comment 5

[Steve Speicher]

From what I mentioned in comment #2 , there has been an enhancement bug 519177 opened that if supported could assist with some of these use cases.

Comment 6

[Matěj Cepl]

(In reply to comment #3)
> (In reply to comment #1)
> > 
> > There's already a standard Java API for Trouble Ticket systems, maybe we can
> > work off of that.
> 
> Any pointer ?

Is it http://jcp.org/en/jsr/summary?id=91 ???

Comment 7

[Matěj Cepl]

(In reply to comment #6)
> Is it http://jcp.org/en/jsr/summary?id=91 ???

And from my non-Java-programmer (actually, non-programmer) look at http://java.sun.com/products/oss/downloads/jsr91_downloads.html I think it is something which we don't want to touch with a ten-feet pole unless we want to rewrite bugzilla into J2EE compliant thing.

Comment 8

[u336811]

OSLC-CM is almost 2.0 now, and is clearly not limited to the Java world... I think it would be the way to go, IMHO.

Comment 9

[Max Kanat-Alexander]

Yes, if we did this, we would use OSLC, not the JSR.