Author Archives: hongbinlu

Hongbin’s screencast


Status Updates – November 28st

– Status:
* Modified installer after a code review by Mike.
* File attachment now works without comments: we are able to attach files, download them, and delete them.
* Commenting is partially done, should be finished within a day or two and then I’ll post the code.
* UI is very rough but functional right now.

– Next Steps:
* Get comments working completely. Need some feedback on how comments should look.
* Get some feedback on how file descriptions should work and on refactoring File attachment out of the “reviews” app.
* Show some ideas for UI and get feedback.
* Start screencast work.

– Roadblocks:
* None.

– Status:
* Got uploading diff’s working. Scripts rb-create and rb-upload both now work.

– Road Blocks:
* None.

– Next Steps:
* Need to understand what rb-patch should do exactly. Polish up the resource-browser (for our screen-cast.) Make any changes based on feedback in

– Status:
* Ran into some git problems that slowed me down a lot and kept me from testing, so it’s hard to tell how close to done my extension is, but it should be getting close.

– Roadblocks:
* Still working on the git issues.

– Next step:
* Finish extension; make sure it works.

– Status:
* Working on support of Bugzilla. Mainly investigating its API and starting writing code by using its API.
* Refining the the code base on feedback from Mike in the code review

– Roadblocks:
* I am not sure it is roadblock or not. I found that most of the Bugzilla server don’t have the REST API installed, which is one of the requirements of my extension.

– Next step:
* Finish the Bugzilla integration.
* Fully test the extension.

– Status:
* Finished global configuration file and accessor rb-diff fixes to client code.

– next week:
* Polishing up code maybe another script or two if we are missing unctionality.

– roadblocks:
* Nope

– Status: Working on user page.
– Road Blocks: None.
– Next Steps: Finish page.

Minutes for the 21th of November

It is a short meeting this week.
* Difference between the status report and weekly plan:
– Goal posts were our way of getting you to schedule yourself for the rest of the term.
– Status reports are to tell us what you’ve done over the past week, and more importantly: what’s keeping you from progressing, if you’re having problems.
* Some roadblocks with dionyses and brendancj: uploading isn’t working correctly.

Weekly plan

Hi Folks,

Currently, I am working on refining the code to support another bug track ‘BugZilla’. The previous one ‘GoogleCode’ is done, but I want to avoid my extension hard code to that. My final goal is to make my extension support 2-4 popular bug tracker and open to other potential bug trackers as well.

Nov 21 – Nov 27

* Finish implementation the support of BugZilla issue tracker.
* If I have time, maybe add support for one more bug tracker.

Nov 28 – Dec 4

* Wrap up for the project. Will do fully test, get feedback from others and revise the code.

Dec 5 – Dec 11

* I believe it is the soft end.

That’s it. Oh yes, I also posted the screenshots of two of several page.

Status Update(Oct11-17)

* Finished up the Resource class and some touches to the ServerInterface.
* Met with Brendan to put our components together and discuss the next piece.
* Next Steps: Get feedback/validation and proceed from there.
* Roadblocks: None.

* At a bit of a roadblock, uncertain where to go next.
* Roadblocks: I commented on the extension idea about exporting comments to Excel 2 weeks ago, asking for more information, but there haven’t been any comments since then. Because of that, I am uncertain what exactly is wanted, i.e. whether it should be CSV or some other type of file read by Excel, and how exactly it should be formatted.
* Next steps: Either get more details on the Excel extension, or pick a different extension to start working on.

* Mainly working on writing bug tracker integration proposal.
* Listening feedback about the proposal from others and revising the design according to those advise.
* Roadblock: None.
* Next steps: I will try to modify proposal. After the proposal has been approved, I will start the implementation.

* Worked out some UI bugs and made the installer presentable.
* Tested the python and setup_tools installation.
* Worked on installing Patch silently –> still in progress.
* Problems: Not sure what Kevin and I are doing on our joint project –> we are talking about it now.
* Next steps: Finish with Patch, install PyCrypto and PIL and the easy_install dependencies.

* Finished up ServerManager (API tool that user interfaces with) and RBUtilities (collection of utility functions), created Repository (which needs a whole bunch of work).
* Met with Lindsey to put our components together Hooked ServerInterface (Lindsey’s ) inot ServerManager( my code ), and started building tools for Creation/Updating/Publishing/Deleting review requests (should be finished by meeting). Lindsey’s better understanding of REST was paramount.
* Next Steps: get feedback.

* Finished invalid user/group bug.
* Finished first version of collapsible reviews.
* Next Steps: revisit post-commit model Web U.I.
* Next Steps: review what has already been worked on.
* Roadblocks: none.

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.

Meeting Minutes: October 10, 2010

The IRC log for this meeting can be found be find here.


* Hongbin: Investigating the Google Code API.

* Lindsey/Brendan : We’ve both done some work on the API to flush out requirements, now we just need to recombine and see what we have discovered.

* kfquinn: Working on fixing the invalid user/group bug, started (and almost finished) the collapsible/expandable reviews.


* Brendan suggest to refer PEP-8 for code standard:

* The reviewboard-dev list is a great resource – not just ChipX86 and purple_cow, but a ton of other developers who might have an opinion or some advice.

* Setting several smaller hard deadlines is good. Break your task into a few chunks and maybe set a hard deadline every couple weeks for that chunk


Q. Do we need a “reviewboard installation directory” for something? Since reviewboard is installed via easy_install?

A. We probably don’t need an actual directory.

Q. Are there any hard deadlines?

A. Dec 7th.