Are there code reviews in opensource projects? If so, what tools are used to do this?

Question

I know there is a big push for code reviews in commercial development. However, are code reviews used in open source software or is based on trust? If so, then how are they performed? [Is it a delayed commit, "a pre commit environment", is there a tool that allows for the patch to be sent to another dev]?

Are there any projects that use code reviews?

From my understanding the Linux kernel is mostly based around trust of the committer. MySQL was based on the main author's approval and the performance impact.

Answer 1

Almost all open source projects use some sort of gatekeeper workflow, where a person or group of people must sign off on all changes in order to go into the official build. Some larger projects, such as the Linux kernel, have layers of gatekeepers. You send a change to someone who manages an area of a subsystem, they send their changes to someone who manages an entire subsystem, and they send their changes to Linus Torvalds, who sometimes reviews the code himself or sometimes trusts his lieutenants. These reviews usually don't have a formal structure. It's just someone looking the code over before it gets merged.

As far as tools, look at the pull request mechanism on github for a good example. You make a pull request, and on a web page dedicated to that pull request people make comments and the author makes revisions until it is good enough to accept. Other gatekeepers just use plain git to apply patches from mailing lists or merge pull requests from public repositories, which is one of the main reasons DVCSes like git were invented.

Answer 2

Open source projects often have (and should, if they don't) a clearly published set of "community guidelines", which often includes a description of the project workflow and how contributions are accepted (and thus how they are tested), as well as the process for becoming a core committer.

As far as code review, again it depends on the community but the guidelines are often made clear. Some example guidelines for contributions by non-committers range from "working code wins" to "contributions must have full test coverage and documentation, with tests committed at the same time as the code" and everything in between; regardless of these guidelines, the one guideline that is implied is that the core committers will review any and all contributions from non-committers before accepting them.

Open source projects with groups of core committers also often have virtual meetings or dedicated time to discuss any contributions that may need extra sets of eyes -- much like the SE process of multiple close votes by users of a certain reputation before a question is closed, and the discussion of questionable things via meta or chat.

Here are a few quick links to some example community documents for projects I know best, where you can find answers to your question specific to these projects (you'll soon notice a theme):

• Project Blacklight community principles
• DSpace code contribution guidelines
• Apache contributors tech guide

Answer 3

Larger OSS projects will have a number of core committers. So I guess they are the de-facto "code reviewers".

Also, since OSS code is by it's nature open to everyone there is likely to be much more discussion around the code you are writing. Whilst this may not be in the form of formal code reviews, you will certainly find out if your code is not considered up to scratch for a specific OSS project.