Proposal for bug tracker integration (Draft)

This document is written to proposal an idea about how to integrate Reviewboard with bug trackers product. Though this document, I will proposal a way to extend Reviewboard to support different kinds of bug trackers, such as GoogleCode, Bugzilla, and so on.

Currently, Reviewboard and bug tracker are independent of each other. Reviewboard provides a platform for code review and bug trackers facilitate the way of keeping track of software issues. Although Reviewboard and bug tracker were often used together for the same software product, we have no way to associate a code review request with one or more specific bug issues.

Proposed solution:
Implement one extension for each bug tracker product. The extension framework should provide following functionalities:
• Reviewboard server admin can choose which bug tracker product they used from a list of supported bug trackers.
• Reviewboard server admin can enable or disable the bug tracker extension.
• For each code review request, the code authors or the reviewers can associate the code review to the specific issue posted at specific bug tracker.
• If a code review post and an issue post have been associated, any status update on code review(e.g. review is open, review has been commented, review has been closed, and so on) will automatically trigger a new comment on the issue post.
• The Reviewboard admin can configure which kind of status update should notify the bug tracker.
• The code authors or the code reviewers can disassociate the code review against the issue. If a code review and an issue have been disassociated, it means any update on that code review will no longer notify the issues tracker.

With the Reviewboard API and existing extension framework, the implementation is straight forward. The general idea is to listen to a specific set of events from Reviewboard and do corresponsive actions for different events. The event handler is mainly for posting comments on bug tracker by utilizing the specific bug tracker API. However, before we can post comments on issue, we should handle the authentication properly.

– authentication
As I mentioned above, the Reviewboard admin should configure which bug tracker they want to use. After the decision is made, he or she should provide an user account and password for that specific bug tracker system. The user name and password(It should be encrypted) will be store on the Reviewboard server. That account will be the only account to authenticate against the bug tracker system. By doing this, we can make sure that we don’t need to authenticate the specific code review users to bug tracker system, which is an overhead for users. In addition, the admin password will be only given to bug tracker so that no Reviewboard’s users will abuse the account.

– Issue association
Under each code review, Reviewboard will provide an option for users to associate current review with one or more issues. Specifically, Reviewboard will query all open issues from bug tracker and put them in a drop down list, in which users can easily choose.

Future work:
After this proposal has been approved, I will try to implement the extension for GoogleCode and Bugzilla first. (Because GoogleCode is the one we use and Bugzilla is the one our customers required) I would suggest to add support for other bug trackers in per request basis.


2 thoughts on “Proposal for bug tracker integration (Draft)

  1. Mike Conley


    That sounds pretty good – sounds like you’ve got your head wrapped around it.

    So, a few things that stuck out for me:

    1: Linking review requests with issues

    I’m not sure if you were thinking about building a mechanism for linking up review requests and issues, because if you are, this mechanism already exists.

    We have the “Bugs” per review request, which lets us link (hyperlink) to issue trackers. (See this review request for example – – it links to issue 1717).

    Or were you thinking of associating/disassociating at a different level?

    2) Authenticating

    That, to me, is the tricky bit. The rest is lots of API glue.

    Storing the encrypted user/pass for an issue tracker account…there might be other ways. For example, I know some APIs just give you an API secret key for an account to use, which makes holding onto the user/pass redundant.

    How does the Google Code API authenticate, for example? Can you post that link that ChipX86 sent you?

    Thanks for this Hongbin – great writeup,


  2. hongbinlu Post author

    1) I haven’t recognize that have already done. Yes, I can possibly reuse the code to do our jobs, which is auto-posting comments on issues when the review status changes. Thanks for letting me know.
    I mentioned associated/disassociated, which just means the auto-comments posting on issue.

    2) Here is the GoogleCode API documentation:

    According to that, there are two ways to do authentication:
    * Authenticate for individual RB users.
    * Authenticate for one admin account.
    The disadvantage of the first is complicated and it is not user-friendly. Users need to have both RB account and GoogleCode account to post the review, which is a overhead. Therefore, I prefer the second, which means RB users can go ahead to post an review without worrying about the GoogleCode authentication.

    You mentioned a private key alternative. Actually, I don’t know the exact details of that method. In the first sight, I will worry about the security issue. I think we should not give any account credential to users, because the users may gain the extra account privileged, which they should not have.



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