HTTP RESTful API for Bugzilla - what's important?
Gervase Markham
To try and help Mozilla Project community members (in particular)
innovate on top of Bugzilla, I'm going to be creating an HTTP RESTful
API for it. As you know, we have some rather diverse requirements for
our bug-tracking tool; hopefully letting people more easily build new
tools and task-specific UIs will ease their pain that the default web
interface is not always all we'd like it to be. [Bugzilla currently has
an XML-RPC API but it has some gaps - e.g. you can't update bugs.]
Initially, I'm going to be implementing this as a proxy, which has the
advantage that its development can be decoupled from the Bugzilla
development cycle and b.m.o. upgrade patterns.
It would be very helpful to have some guidance as to what functions are
most important, so I know what to do first. If you were writing a web or
other app to help you with tasks in Bugzilla, or wanted to integrate it
with tinderbox or some other tool, what would you need to be able to do?
For example, I seem to remember hearing from shaver that the
capabilities to get and change flags, and attachment metadata, were
particularly important to him. I'd love to work with people interested
in writing clients of some sort.
Also, what format do you want it in? I'm assuming JSON and JSONP, with
XML to follow as a secondary goal, but tell me if I'm wrong.
Guidance on where else to ask this question would also be helpful. And
if you have experience in REST API design, please help us out in
mozilla.dev.apps.bugzilla.
Thanks :-)
Gerv
Robert Kaiser
> It would be very helpful to have some guidance as to what functions are
> most important, so I know what to do first. If you were writing a web or
> other app to help you with tasks in Bugzilla, or wanted to integrate it
> with tinderbox or some other tool, what would you need to be able to do?
I have a SeaMonkey release radar watcher set up on dev.seamonkey.at
where it would be quite helpful to get the counts on bug queries even
more easily than setting the query ctype to microsummary and extracting
the number from the brackets ;-)
Robert Kaiser
Mark Banner
> It would be very helpful to have some guidance as to what functions are
> most important, so I know what to do first. If you were writing a web or
> other app to help you with tasks in Bugzilla, or wanted to integrate it
> with tinderbox or some other tool, what would you need to be able to do?
Pike and I both have semi-automated new bug template production (see [1]
for my version). There's some things that you can't do via the existing
bookmarkable template functionality e.g. set flags, set status
whiteboard. These would be useful in extending my version at least.
I guess fully-automated submission would be useful as well, but probably
not a priority.
Standard8
Rob Arnold
> Hi everyone,
>
> To try and help Mozilla Project community members (in particular) innovate
> on top of Bugzilla, I'm going to be creating an HTTP RESTful API for it. As
> you know, we have some rather diverse requirements for our bug-tracking
> tool; hopefully letting people more easily build new tools and task-specific
> UIs will ease their pain that the default web interface is not always all
> we'd like it to be. [Bugzilla currently has an XML-RPC API but it has some
> gaps - e.g. you can't update bugs.]
I've been forging HTML POSTs to update bugs - a real API here would be nice.
> Initially, I'm going to be implementing this as a proxy, which has the
> advantage that its development can be decoupled from the Bugzilla
> development cycle and b.m.o. upgrade patterns.
>
> It would be very helpful to have some guidance as to what functions are
> most important, so I know what to do first. If you were writing a web or
> other app to help you with tasks in Bugzilla, or wanted to integrate it with
> tinderbox or some other tool, what would you need to be able to do? For
> example, I seem to remember hearing from shaver that the capabilities to get
> and change flags, and attachment metadata, were particularly important to
> him. I'd love to work with people interested in writing clients of some
> sort.
Currently for qimportbz, I need to be able to look at attachments and all
their flags. I eventually want to extend qimportbz so that you can post
patches from your mq to bugzilla and sync the patches posted to a bugzilla
bug to your local patch queue - this requires knowing the bug history so
that I can infer patch replacements. Bug history is not currently exposed as
XML in b.m.o so I cannot progress on syncing.
> Also, what format do you want it in? I'm assuming JSON and JSONP, with XML
> to follow as a secondary goal, but tell me if I'm wrong.
For qimportbz, I'd strongly prefer XML because I can parse it with python's
standard library (JSON is new in 2.6 - not sure which Mercurial versions
ship with that - it might even vary per platform).
-Rob
Samuel Sidler
"... please help us out in mozilla.dev.apps.bugzilla." means "not in
mozilla.dev.planning".
-Sam
On Sep 8, 2009, at 12:34 PM, Rob Arnold wrote:
> On Tue, Sep 8, 2009 at 1:09 PM, Gervase Markham <ge...@mozilla.org>
> wrote:
>
>> Hi everyone,
>>
>> To try and help Mozilla Project community members (in particular)
>> innovate
>> on top of Bugzilla, I'm going to be creating an HTTP RESTful API
>> for it. As
>> you know, we have some rather diverse requirements for our bug-
>> tracking
>> tool; hopefully letting people more easily build new tools and task-
>> specific
>> UIs will ease their pain that the default web interface is not
>> always all
>> we'd like it to be. [Bugzilla currently has an XML-RPC API but it
>> has some
>> gaps - e.g. you can't update bugs.]
>
>
> I've been forging HTML POSTs to update bugs - a real API here would
> be nice.
>
>
>> Initially, I'm going to be implementing this as a proxy, which has
>> the
>> advantage that its development can be decoupled from the Bugzilla
>> development cycle and b.m.o. upgrade patterns.
>>
>> It would be very helpful to have some guidance as to what functions
>> are
>> most important, so I know what to do first. If you were writing a
>> web or
>> other app to help you with tasks in Bugzilla, or wanted to
>> integrate it with
>> tinderbox or some other tool, what would you need to be able to do?
>> For
>> example, I seem to remember hearing from shaver that the
>> capabilities to get
>> and change flags, and attachment metadata, were particularly
>> important to
>> him. I'd love to work with people interested in writing clients of
>> some
>> sort.
>
>
> Currently for qimportbz, I need to be able to look at attachments
> and all
> their flags. I eventually want to extend qimportbz so that you can
> post
> patches from your mq to bugzilla and sync the patches posted to a
> bugzilla
> bug to your local patch queue - this requires knowing the bug
> history so
> that I can infer patch replacements. Bug history is not currently
> exposed as
> XML in b.m.o so I cannot progress on syncing.
>
>
>> Also, what format do you want it in? I'm assuming JSON and JSONP,
>> with XML
>> to follow as a secondary goal, but tell me if I'm wrong.
>
>
> For qimportbz, I'd strongly prefer XML because I can parse it with
> python's
> standard library (JSON is new in 2.6 - not sure which Mercurial
> versions
> ship with that - it might even vary per platform).
>
> -Rob
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
Gervase Markham
> "... please help us out in mozilla.dev.apps.bugzilla." means "not in
> mozilla.dev.planning".
Well, I was hoping for help in API design in mozilla.dev.apps.bugzilla,
but thought suggestions for functionality prioritization were best here,
which would put Rob's message on-topic.
The reason I wanted to have that discussion here is that I think this
group has a number of people who regularly wish "if only I could do X
with Bugzilla".
Gerv
Gervase Markham
> I've been forging HTML POSTs to update bugs - a real API here would be nice.
That's what we'll probably be doing on the back end to start with :-)
but hopefully we can provide you with a real API.
> Currently for qimportbz, I need to be able to look at attachments and all
> their flags. I eventually want to extend qimportbz so that you can post
> patches from your mq to bugzilla and sync the patches posted to a bugzilla
> bug to your local patch queue - this requires knowing the bug history so
> that I can infer patch replacements. Bug history is not currently exposed as
> XML in b.m.o so I cannot progress on syncing.
This is very helpful - thank you.
Gerv
harthur
> It would be very helpful to have some guidance as to what functions are
> most important, so I know what to do first. If you were writing a web or
> other app to help you with tasks in Bugzilla, or wanted to integrate it
> with tinderbox or some other tool, what would you need to be able to do?
Posting attachments to bugs and getting the results of advanced search
queries are two things that I've needed multiple times from a Bugzilla
API. As a current consumer of the XML-RPC API, I would like to see
the ability to create bugs and view legal values for a field to be
retained. Also, the ability to get more information about each bug
would be nice, including comments. JSON yes.
Gervase Markham
> Posting attachments to bugs and getting the results of advanced search
> queries are two things that I've needed multiple times from a Bugzilla
> API.
By that, you mean a search API which is as flexible as the web form we
have today?
> As a current consumer of the XML-RPC API, I would like to see
> the ability to create bugs and view legal values for a field to be
> retained. Also, the ability to get more information about each bug
> would be nice, including comments. JSON yes.
Thank you :-)
What do you currently use the existing API for?
Gerv
harthur
> By that, you mean a search API which is as flexible as the web form we
> have today?
Yep, exactly. Right now I use a wrapper function that takes in a JSON
object that corresponds to the parameters for buglist.cgi, then parse
the atom ctype results like Robert (-:
> What do you currently use the existing API for?
I currently use the XML-RPC API for authentication, creating bugs, and
getting information about bugs.
-harthur
Clint Talbert
> On 08/09/09 21:04, Samuel Sidler wrote:
>> "... please help us out in mozilla.dev.apps.bugzilla." means "not in
>> mozilla.dev.planning".
>
(unless I'm missing something), I'm going to throw my two cents in
rather than fragment the thread.
> The reason I wanted to have that discussion here is that I think this
> group has a number of people who regularly wish "if only I could do X
> with Bugzilla".
>
whiteboard or keyword fields. If we use this API to build ourselves a
bugzilla triage workflow (something I think would be useful) then we'll
need access to those fields.
The Get should get all the items in the field
And put should overwrite all items with the new value. (see below)
For the ease of the API and the implementation, I'll recommend a simple
get/put that overwrites the existing values with new ones. That means
the APIs we make from this will have to own parsing the whiteboard and
making certain that any whiteboard flags that are not affected by
operation will be preserved. I think that's easier than trying to have
the General API be smart about parsing the whiteboard.
Clint
Gervase Markham
> I don't see on the API that you have a mechansim to get/set the
> whiteboard or keyword fields. If we use this API to build ourselves a
> bugzilla triage workflow (something I think would be useful) then we'll
> need access to those fields.
You can edit the bug (/bug/<id> PUT), which includes setting those
fields. You just specify the fields you want to change; you don't need
to specify fields which aren't changing.
> For the ease of the API and the implementation, I'll recommend a simple
> get/put that overwrites the existing values with new ones.
Yes, that's the plan. (Although the main /bug/<id> PUT API will detect
prior modifications and return an error, which you will need to deal
with intelligently, perhaps by doing user-guided client side merging).
Gerv
SteveS
Have looked at supporting an evolving standard on this?
We have collaborated on a set of resource formats and RESTful APIs
around bug tracking (change management) tools.
The group currently includes: IBM, Oracle, Tasktop / Eclipse Mylyn,
Rally Software, SourceGear, BSD group, Accenture, ...
A number of us have already implemented the service provider: Rational
ClearQuest, Rational Team Concert, Rational Change (formerly Telelogic
Change) as well as consumers being Tasktop and Rational Quality
Manager, more expected soon.
We have coined it OSLC (Open Services for Lifecycle Collaboration) and
more information is available at http://open-services.net/bin/view/Main/CmHome
We'd love to have you join the community and work on developing
upcoming versions of the specification.
Let me know if you'd like more information.
Steve Speicher
Gervase Markham
> Have looked at supporting an evolving standard on this?
>
> We have collaborated on a set of resource formats and RESTful APIs
> around bug tracking (change management) tools.
> The group currently includes: IBM, Oracle, Tasktop / Eclipse Mylyn,
> Rally Software, SourceGear, BSD group, Accenture, ...
Hi Steve,
Sounds interesting; the Bugzilla team were surprised not to have come
across it before. At the moment, implementation timescales and progress
already made mean I'm not going to change horses mid-stream; but
anything's possible in the future.
https://bugzilla.mozilla.org/show_bug.cgi?id=519177
Gerv