Author Archives: weilul

UCOSP Blog Post – March 12, 2012

My name is Wei Lu Liu. I joined the Review Board team this semester as an undergraduate computer science student from Simon Fraser University. Gaining some open source development experience is what drove me at first, but being part of Review Board is far more than this. Throughout our development, we employ

– Git for revision control

– Google Groups/Code/Wiki/Blog for administration and reporting

– IRC/PasteBin for instant Q&A and discussing

– Review Board !!

Here comes the unique and interesting experience about working on Review Board: we are using Review Board itself in our development, which gives us first-handed feelings and feedback. With the “free” feedback, we can make Review Board better satisfy the developers as well as ourselves. With the goal of making our own lives easier, everyone in the team seems to have great interest and motivation.

So far I have had my hands on three bugs or projects. I would like to discuss my experience about each of them.

*  Adding “confirm password” fields to Review Board installation

The Review Board installation process has a couple of pages that ask the user to enter a new password, but the users do not have the chance to confirm their password. This project is a little different from others, as it is majorly about PyGtk. Without a whole understanding of PyGtk, I got stuck right after I added the “confirm password’ fields to the pages. I was trying to find some functions in that page class that validate the new field. I spent several hours but was still blocked. It is lucky that my mentor pointed out that the validation should be a widget. It turned out he was right, and we quickly worked it out.

This small  bug fix taught me that the Review Board is a quite big project that utilizes many third party packages like PyGtk. Although I considered myself good at Python, it is far from enough to handle the whole project.

* Tracking the users that change the review request

This project is about the product itself. It covers most of the main features of Django. The first thing I was faced with was to alter the database, more specifically, to add new fields to the tables to store the information and alter the restrictions and relations among the fields and tables. Django abstracts a table as a class, but adding a field to the table does not simply equal to adding a variable to the class. We have to make it happen to the real database using a tool called Django Evolution. I got stuck here again. I tried many tutorials online but just could not make it work. After consulting our mentors, I solved the problem and found that it was because I wrongly understood what Git does. In our case, Git only controls the source file types such as .py/.html/.js. The database file, .db typed, is not in its charge. So when I switched between branches the database file stayed the same. I learned that the details are important; I need to get more familiar with these software development concepts.

Altering the database successfully made it possible for me to quickly realize the user tracking features.I thought the project was about to finish, until our mentors raised some concerns: what if multiple users are making changes to the same review request? Whose change gets published? This is the famous race problems in transaction control. We decided to have a banner to tell the user not to confirm if there was another user editing the same page. This experience taught me that testing is so important in software development. Without the help from my mentors, I may think I was done with the project. Review Board has a unit test for every app, running and analyzing them is extremely import if I want high quality work. I was quite interested in those test cases and would see if I could learn writing some by myself.

* Weekly email updates

“Finding out what’s been happening on Review Board isn’t always easy. It might be worthwhile to have users be able to opt-in to weekly email updates from Review Board that tell them useful things about the groups that they belong to.” This is the idea why we want this feature. Django actually has really good email support. Review Board extends it and have specifically customized email methods itself. You should have realized that this project is more of administration level. I will write an admin command to realize it. I am just starting with it, and it looks interesting for me.

It is only one month left in this semester. I feel that I wasted a lot of time when I got stuck. I thought too much but did not ask enough questions. I have the shortcoming that I always want to have some basic idea before I ask questions. However, it usually turns out that I can not even have correct basic ideas if I just keep thinking and not asking, since the industry project is way more complex than the academic projects we do at school. Fortunately I have really helpful and friendly mentors and students in our team. After asking a couple of stupid questions, I got myself more familiar with the whole project. Now I can ask more meaningful questions after some self-exploration at first.

I am really grateful to UCOSP. I think it is a really good program for undergraduates. I did some internships before, but I felt that I could learn so little about the details of software development there. The internship employers, at least in my case, tend to put us on the works that are less risky for us to do. After all, they have too many things to consider, and we usually could not learn as much as we want. The UCOSP program is different, since everyone in the team have the same interest and goal: to learn and to contribute. In our case, the Review Board, if we can make it a better tool, it would be for the benefit of all the developers using it. Due to this reason, I think UCOSP is a really good program that compliments our academic and internship experience. I hope this program can continue evolving and benefiting more and more students.


Wei Lu Liu (Willer)


Meeting Minutes – Feb 11, 2012

Attendance: all mentors and students.

– Mike announced that mentors will determine part of our grades base on: 1) being pesent, 2) communication, 3) how well you take the code review criticism & 4) your projects. Nothing have we heard from the universities about the evaluation.

– Yazan was suggested to make the required field flag a star with “(required)” at the end and set required=”required”. On the summary table, Yazan would make a filter instead of collapsing (a little dropdown or toggles above it for showing opened issues or all; default to opened issues).

– Wilson has recovered and is doing well with his current review request. He will pick up another project soon.

– Steven learned from Mike and Christian that the WebHooks being blocked automatically is fine for now and that the POST request it sends should use JSON. Steven proposed to make some tools that can retrieve from the code base. Christian had three alternatives: pointing to the review board database, having an own clone of database or making some channel. They would talk about another issue, djblets extensions admin, afterwards.

– Jim learned some routines to involve djblets 0.6.x and see remote branches from Mike and David. He would need his master updated in this case.

– Dave had an OSError in his VM when he had to restart the dev server after file changes. Mike suggested him to try a fresh clone, and they would resolve the error later.

– Curtis wanted to look at similar some code on template hooks. Mike would show him how to use the review-summary-header-post hook after the meeting.

– Anthony had email issues. he would start looking at some unit tests (e.g. notifications/ Christian and Mike mentioned.

– Wei asked how to manually test his project. Mike suggested to set up a repository for the local reviewboard install, connect it to the actual Review Board Github repository, generate diffs against the current Review Board source, and post them to the local instance.

REMINDER —- Feb 28: status reports, Wilson; minutes, David.

Status Reports – February 4, 2012


  • Fleshed out basic options for the other hooks (ReviewRequestActionHook,
    DiffViewerActionHook, working on ReviewRequestDropdownActionHook)
Next steps
  • I’m going to look into picking up another project
  • Not sure if I should add this to the code review I already have out, so
    I’m waiting for some movement there


  • Working on simple WebHooks extension
Next steps
  • ReviewBot
  • None


  • Trying to fix a bug that’s preventing me from checking-in previous
  • Reading the diff utility code and see if I can re-use it and come up
    with a prototype for description change renderin
Next steps
  • Keep on what I am currently doing
  • None


  • Working on moving summary table/adding buttons
  • Adding required fields to review request
Next steps
  • Submitting features for review
  • None


  • Better familiarized myself with code base of project scope (better moved
    files in diff viewer)
  • Planned and started coding project
Next steps
  • Continue working on project
  • None


Next steps
  • Start the back end work required for the reviewboard-social extension, while the designs for the interfaces are reviewed and modified
  • None


  • Sick, green phlegm everywhere
Next steps
  • Get better
  • Nasal congestion

– Sorry I haven’t done much this week, not feeling well at all


  • Made changes to r/2818 according to the comments and retested; got it pushed to master; closed r/2818
  • Starting project “Tracking User Changes” by reproducing the behavior on local test server
  • Downloaded and applied the starting code for project “Tracking User Changes” from previous review post r/2615
  • Researched the source code and diff for the project; learned django template syntax btw
Next steps
  • Started coding for the project
  • Hopefully posted a review request when early changes are done
  • The project has been related to 8 files and 15 changes already; only intuitively understood the relationship between them so far; wish to get some extra help separately on their relationship

Wei: Code Sprint Report – Winter 2012


– Setup the development environment

– Understood some basic project ideas

– Fixed a bug in rb-site and post the review request

Next step:

– Follow up with the comments on my review request of rb-site

– Learn Django template language in order to touch the main projects

– Pick “Tracking User Changes” as my first project, starting by exam how “Tracking User Changes” is done


– I was really happy to see everyone during the sprint; everyone is very friendly; good luck and have fun for everyone!

– The open source development environment feels very efficient and comfortable


– I put too much effort on rb-site, did not get aware of the other main projects; now I am starting my own project, so it is time to write this sprint report



Wei Lu Liu