Publishing code reviews

Mark Reinhold mr at
Thu Oct 11 17:41:05 UTC 2007

One of the engineering practices that's served the JDK development team
well for many years now is that of peer-based code reviews.  In mainline
JDK development at least one review is required for every code change,
and two or more are needed as release milestones approach.

Reviews are most often performed with the help of a tool called "webrev",
which basically diffs two source trees and generates a pile of HTML that
you can view in a browser (sample: [1]).  webrev was originally written
by the Solaris team; lately it's been revised and extended [2] to support
Mercurial and Subversion in addition to the old internal TeamWare SCM.

A lot of the e-mail that JDK developers read and write is, naturally,
about code reviews.  It's not exactly convenient to attach webrevs to
e-mail messages, so people typically either copy them to a directory
published by a private web server and send the URL around, or they copy
them over to an NFS-exported filesystem and send a long pathname (and
cross their fingers if a potential reviewer is far away network-wise).

The bug here, of course, is that these publication methods don't make
code reviews visible on the open web, and this is one reason that most
JDK developers have thus far been reluctant to move more of their e-mail
traffic onto the public mailing lists.

So: How should we solve this problem in a way that works for all JDK
contributors, whether or not they work for Sun?

We could build something slick and fancy, like Google's Mondrian [3],
but I think it's relatively more important to get something up quickly
and work on improving it later.

A more expedient solution would be to construct something like the
OpenSolaris code-review site [4,5], where contributors can use rsync,
scp, and sftp (all via SSH) to upload webrevs to temporary storage on
a public server.  SSH keys will ultimately be required in order to push
changesets into the public Mercurial repositories, so contributors will
need to create and register SSH keys anyway, and the code-review site
can easily leverage the same underlying infrastructure.

Comments?  Alternatives?

- Mark


More information about the discuss mailing list