A case study of Apache peer/code review processes

Posted by Greg Young on Aug 01, 2007 05:50 PM

Community

Architecture

Topics

Debugging ,

Delivering Quality ,

Code Analysis

Peter C. Rigby and Daniel M. German of the Software Engineering Group at the University of Victoria under the supervision of Margaret-Anne Storey have released A case study of Apache peer review. This paper has also been submitted to FSE2007. The paper is a follow-up to a previously released technical report A preliminary examination of code review processes in open source projects released in 2006 by Peter and Daniel which analyzed the code review processes of Linux, GCC, Mozilla, and Apache.

The new case study targets Apache specifically and seeks to answer the following research questions:

• Process: What types of review are performed and what are the processes for conducting those reviews?
• Frequency and Activity: How often are the reviews performed? Is the frequency of review related to the development activity?
• Participation: How many developers participate in the review? How much discussion is there during a review?
• Size: What is the size of the artifact under review?
• Interval: How long do reviews take to perform?
• Defects: How many reviews find defects?

In answering these questions the paper presents both the CTR and RTC review processes used by the Apache project as defined in the Apache glossary:

Commit-Then-Review (CTR): A policy governing code changes that [grammar edited] permits developers to make changes at will, with the possibility of being retroactively vetoed. C-T-R is an application of decision making through lazy consensus. The C-T-R model is useful in rapid-prototyping environments, but because of the lack of mandatory review it may permit more bugs through than the R-T-C alternative

Review-Then-Commit (RTC): Commit policy, which requires that all changes receive consensus approval in order to be committed.

'Consensus approval' refers to a vote, which has completed with at least three binding +1 votes and no vetos.

Included in the analysis of the review processes is a discussion of the strengths and weaknesses of each. Unlike the Apache project, commercial development environments tend to favor the RTC process in dealing with code reviews (often said with a basis of risk management, considering it better to lose a change than to have a bad change make it into your source base). This discussion could be used to make a convincing argument towards the viability of CTR in commercial environments. The discussion and analysis of the CTR process is also of importance as data related to the process is lacking.

Also under analysis is the size of artifact being reviewed, Apache (and other projects) use a “Review Early, Review Often” mentality, Apache in particular “performs reviews at drastically higher frequency, shorter interval, and with smaller artifact size” in comparison with Porter et al.’s findings. The trade offs associated with these smaller artifacts become an important topic of discussion.

Another critical discussion focuses on the mediation of defects:

With formal review techniques, the discussion centers around defects. A good mediator does not allow reviewers to start discussing anything but defects. The developer must fix the defect and report to the mediator when the problem is solved.

It then contrasts Apache’s methodology in that

The reviewers are not interested in the defect, but in what caused the defect and how it can be fixed. The discussion immediately turns from “we found a defect” to “what is the fix for the defect”.

The paper concludes that that the “ideal time to find a solution to a defect is when it is found because all participants understand the problem”. It also finds that “this is not possible in traditional inspection due to time constraints” comparing in specific an example from Lessons from Thee Years of Inspection Data, by Edward F. Weller.

Although some question the harvesting methodology and the lack of interaction with Apache team members, the papers offer an interesting set of discussions comparing and contrasting various review methodologies and should be of use to anyone setting up review methodologies in either an open source or a commercial environment.

1. Back to top

   I love open source

   Nov 26, 2007 8:42 AM by Joseph Then

   I love the concept of open source. That should be a way for the future of the Internet.
   
   It will be good to go beyong Review-Then-Commit by having another review?

   Reply

2. Back to top

   Re: I love open source

   Nov 24, 2008 12:38 PM by emrah okay

   With twenty-four members plus two spec leads, Java EE 6 -- or JSR-316 -- is officially underway, Roberto Chinnici presents a summary from the first meetings between the group sohbet oyun indirindir program chatanyone try to appropriate the IP and patent it without OpenID's consent.

   Reply

• Older >