Publishing code reviews

[Dmitri Trembovetski]

Dmitri Trembovetski wrote:
> 
>   Hi Mark,
> 
>   what about moving one of our our internal code review tools
>   to an outside server?
> 
>   Like the one the client team uses - the 'code review robot'.
>   You submit the code review either via email or web page.
>   The webrev is then hosted on the "robot system" so the reviewers
>   can see it.
> 
>   The communication between the reviewers happens via email, the
>   robot is CC-ed. The tool supports multiple fix revisions,
>   approvals, etc.
> 
>   It will probably need some polishing up - since currently
>   there's no authentication, for example, but it's been used

   As for authentication, we could make it available only to those
   who have the "proper" accounts - we'd have to do that anyway
   for hg access, right? At least that would work until we
   find time to add authentication to the tool itself.

Andreas Sterbenz wrote:
 > I consider the solution used by the Solaris team perfectly adequate.
 > We can always upgrade to a better solution later on.

   Those who had worked with this tool would find what OpenSolaris
   has not at all adequate..

   Thanks,
     Dmitri



>   by many people for a long time and is found to be very
>   convenient if not as flashy as Mondrian and some ajaxy tools..
> 
>   Thanks,
>     Dmitri
> 
> 
> Mark Reinhold wrote:
>> 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 openjdk.java.net 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
>>
>>
>> [1] http://cr.opensolaris.org/~dp/i2o-del/
>> [2] http://blogs.sun.com/dp/entry/webrev_revised
>> [3] 
>> http://www.niallkennedy.com/blog/archives/2006/11/google-mondrian.html
>> [4] http://cr.opensolaris.org/
>> [5] http://blogs.sun.com/dp/entry/cr_opensolaris_org_a_work