Code reviews are vital to the success of any software project. In Open Stack, code must be reviewed to be accepted. If there are not enough people doing code reviews, the reviews get stagnant, and the project can’t move forward.

Right now, there are only three active core contributors focused on Keystone.  There are a couple people that are core on multiple projects the pay attention to Keystone from time to time, but mostly it is just three of us.

How the review scoring works

On Keystone, we need a total of +4 before merging a commit. This means:

Two core at +2 each.
or
Two community at +1 each and One core at +2.

I could say four community at +1 each, but a core member still needs to click “approve” so their name goes on it anyway.

If the patch is created by one of the core team members, they can’t review or approve it.  If we rely only on the core developers, and one of use writes the patch, all three of us have to be involved. That is fine for really important things, and sometimes we want to hold a patch until the other core see it.  But it doesn’t scale.

How to get involved

Find a review request and review it.  Even if it has been reviewed by someone else. If anything at all seems out of place, -1 it and place a reason on it. If the original author thinks your reason is not sufficient, they will let you know. You can decide remove it later.  If you review something and you don’t understand it, put questions into the review. Feel free to -1 it until you understand the rationale. We are very unlikely to merge something that has a -1 next to it, but we have enough confidence in our convictions that we will do so if we feel warranted. Most of all, if a code review has a -1, the person who posted the patch will want to address it quickly, as most people won’t bother reviewing a patch that already has a -1.  If you criticism is at all warranted, the author will address it and submit another patch.

I assure you that we will take a review more seriously if it has negative comments and constructive criticism than if someone just says “Looks Good.”  If the patch is non-trivial, it will have something that can be improved.

Ask question, get involved, and keep things moving. I assure you, it means that once you post code for review, your review requests will get more attention as they come in.

What to review

You may be wondering how to track what code reviews are out there.

For the Keystone Server, the review requests are here.

Here are the review requests for the client.

You will need a launchpad account. More information here.

How to get comfortable better at code reviews

So, how do you review code? Good question. It can be daunting looking at a brand new code base, and a change you don’t understand. Make the review process be your way of understanding the code better.  I’d recommend actually running  the code.   My previous post talked through how to get to that start state.  Set a break point and step through the code.  Look at the parameters that are sent in to the functions.

Here is a list of things you can think about while looking at the code.

There are some things that are specific to Open Stack worth mentioning.

• Eventlet is a greenthreaded Web server.  Blocking calls in native libraries can make it hang.
• We want to be able to support Apache HTTPD as well as Eventlet, so Eventlet specific code needs to be isolated.
• You can see the code coverage by running ./run_tests.sh –coverage, which will generate an HTML based report in keystone/covhtml. Look at the code that was submitted and make sure it is 100% covered
• No code will get merged if it can’t pass the unit tests and functional tests.  Don’t be worried that you will approve something that is broken.
• If a patch is submitted without a blueprint or a bug, and it is not clear what problem the patch is solving, that is sufficient grounds for a -1.   The code may be perfect, but it needs to be documented.
• We are very concerned about backward compatibility.  Keep an eye on any patches that may change previous behavior.

Feel free to ask me questions. As you can tell, I am not shy, and I try to be n00b13 friendly, especially if you are showing an interest and trying to make Keystone and Open Stack better.

If you are wondering how to get involved in Open Stack, I suggest you do some code reviews.