Greetings! Last Sunday at 4PM Eastern (1PM Pacific), we had our first meeting of the semester, with a brand new set of students. Here they are, in no particular order:
- classy_baboon (Behzad Raeisifard)
- edwlee (Edward Lee)
- Tweek (Allisa Schmidt)
- elaineM (Mary Elaine Malit – prefers Elaine)
- endee (Natasha Dalal)
And here’s what we talked about…
Environment types and set-up
- classy_baboon is on OS X 10.8, and at the time of the meeting still needed to get his environment set up
- edwlee is on OS X 10.8.4, and has his environment ready
- endee is on Ubuntu 12.04, and has her environment ready (and will look into getting a VM set up)
- elaineM is using Ubuntu (presumably 12.04), and has her environment ready, but is unsure of how to proceed into the codebase
- Tweek is on Ubuntu 12.04, and has gone through all of the set-up steps, but has not yet run any tests
A Brief Primer on Review Board
- Review Board is used to review patches before (or sometimes after) they’re committed to a repository
- In the “before” case, a.k.a. pre-commit review (which is the one we use for RB development), somebody makes a change locally, puts the patch for the change up on RB, and then other people start examining it and looking for ways it could be better
- Sometimes it’s not just about finding ways it could be better – sometimes it’s also to ask questions about the patch, to find out how part of it works. And sometimes it’s also to compliment somebody on a particularly awesome piece of coding. 🙂 Really, it’s just “Here’s a change – what do you all think?”
- Other teammates tell you what they think, and when the general consensus is that it’s fit to ship, you’ll get some Ship-it’s, and then that’s considered permission to land in the repository
- RB does not do the landing for you – at least, that functionality is not built-in
- Reviewing code is great for knowledge transfer. If I review a change, I now know more about what’s going on in part of the code base
- Think of it as a web-based tool that has access to your code repo – but it’s more interested in proposed changes to the repo, as opposed to the current contents.
How Similar is Review Board to Gerrit?
- Both do code review.
- Gerrit is only for Git
- Gerrit was developed to be a basic code review tool that sits directly on top of a Git repository, on the same server as the Git repo
- Review Board works with Git, Mercurial, Perforce, Subversion, Bazaar, Clear Case, CVS, Plastic
- Review Board is also capable of reviewing things other than code, like PDFs and images.
- Review Board focuses on a streamlined reviewing experience, and optimizes things from the developers perspective, as opposed to the management perspective.
Other facts about Review Board
- Can be used both externally (for open-source projects, like Review Board itself!) or internally, so that only employees on a company network can reach it. VMWare has an internal Review Board instance, for example. So does Amazon and Twitter, and probably lots more. Here’s a (very) partial list of company’s using Review Board.
- Review Board uses Review Board to review patches, and we use pre-commit review. All patches must be reviewed before landing!
How Review Board works (at a really high level)
- Review Board backed by a database which knows about users and other info. In RB’s case, that database also stores things like review requests, comments on review requests, etc.
- When you send a patch to RB, it does some processing on it, and then stores it in its database
- A patch is a file representing a change to a code repository. If I alter some Python code, and want to get the others to look at it, a “patch” gets generated, which represents the change I made (which can apply to multiple files), and that change is uploaded to Review Board as a review request. Here’s an example Review Request.
- At the top of that link, ChipX86 is giving a high-level description of the goals of the change, and if you scroll down, you can see the actual changes
- Here’s the actual patch file that was uploaded to Review Board. The SCM tool for your repository is able to generate that.
- Patches used to be emailed around for code review. That sucked for obvious reasons. Review Board makes things way better.
- Review Board lets you comment directly on the line (or lines!) of code. And then respond to those comments.
How do I start working on Review Board?
- One approach is to look at the smallest units, and work your way up. One of the smallest units in Review Board are the models (Django, which Review Board is built on, uses a Model-View-Controller like pattern – though it calls it Model-Controller-Templates for some reason). The models are (usually) representations of things stored in the database. Check out the various models.py files within the various Review Board subdirectories.
- Here is a (slightly out of date) illustration of the models in Review Board and their relationship.
- Here’s how to run the unit tests.
- Unit tests might break, especially around stuff like pysvn. That’s why working with smacleod’s vagrant set-up might be an easier way to get off the ground.
- Also, maybe study up on Django, and how Django applications are structured.
- You don’t need to set up MySQL or Postgres to work on Review Board. prepare-dev.py will build a SQLite database for you, and that should be good enough. Note that SQLite databases are just a single file, which are handy for copying and backing up.
- Hack on these EasyFix bugs to get your feet wet. Just comment in the bug saying that you want to work on it, and we’ll consider it assigned. If you see a comment like that from a name you don’t recognize from the student list at the top, go ahead and snag it.
- And once you have an EasyFix bug, get started! Ask in #reviewboard-students for tips on how to get started and where to look for things.
- The fill-database manage.py command is useful for pre-populating your dev environment with filler data.
The course structure
- Students are assigned and start getting their development environments set up
- Students start hacking on EasyFix bugs to get familiarized with the codebase, the tools, and the workflow
- The sprint happens. We meet, we greet, we shake hands and high-five, and we hack. Eventually, students will choose bigger projects (list of potential projects to be posted soon).
- Students hack on their projects. They ask questions. They post code frequently in review requests to get early feedback. Mentors (and the other students!) look at the review requests, and make comments / suggestions, and give guidance.
- Some students complete more than one project. That’s fine. Work as best as you can – slow is smooth and smooth is fast.
- There’s a single mid-term evaluation where you get an idea of where you stand, and a final evaluation. We’d like you to have the code for at least one project in the final stages of review (if not completely landed) by the time the final rolls around.
- Students will blog throughout – they will likely be assigned weeks where they must put up a blog post. Students will also be assigned dates on which they must collect status reports from one another (for pre-meeting preparation) as well as assembling post-meeting minutes (like these, but far less detailed)
OMG ASK QUESTIONS
- That’s kind of the name of the game for this course. This course is not about working on your own trying to solve bugs and getting frustrated. This course is about working on a team of people to hack on something really cool.
- If you’re stuck, just ask. Your mentors are here to help. Seriously.
Get an IRC bouncer
- Bouncers are mentioned here and are completely awesome. You want one. Ask ChipX86 and he’ll hook you up.