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). The webrev tool was originally written by the Solaris team; lately it’s been revised and extended 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 very convenient to attach webrevs to e-mail messages, or to read such attachments. People therefore typically either copy webrevs 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 OpenJDK mailing lists.

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

We could build something slick and fancy, like Google’s Mondrian, 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, 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?

(Please direct followups to the discuss@openjdk.java.net mailing list. If you haven’t already subscribed to that list then please do so first, otherwise your message will be discarded as spam.)