OpenJDK Code review system - Request for use cases and requirements

[Steve Poole]

On 18/04/11 11:32, Alan Bateman wrote:
> Mohan Pakkurti wrote:
>> Hello
>>
>> I am looking at undertaking some projects to help improve the 
>> infrastructure for OpenJDK.
>> One of the systems that is often requested is an open code review 
>> system, and I want to understand what we would want from this.
>>
>> I came across this blog entry 
>> http://blogs.sun.com/mr/entry/open_webrevs and want to get this 
>> discussion started again by asking you for input.
>>
>> What use cases would you have for this system?
>> What features would you like to see in this system? What other 
>> systems and processes do you see the code review system integrate with?
>> Any suggestions for systems we should consider for this?
>> Do you have any other comments on this topic?
>>
>> Cheers
>> Mohan
> I see all the replies so far are from Oracle folks and it would be 
> good to get input from others too. It may also be useful to see what 
> other open projects are using, if anything.
>
I'm asking around in my team to see what we think.  So either via me or 
directly we'll post our responses soon.

A couple of interesting questions about a review system is whether its 
pre or post commit, and if it's pre - is it intended to be the gate into 
the repository. By that  I mean that an authorised person could press a 
button and the changeset is commited to the repository.   I like having 
the review system be the gate into the repo. That way you know that the 
code for review is the change that will be made.  A good example of a 
review tool that works that way is gerrit.     Having used reviewboard 
and gerrit  I have to say I like gerrit better but it has its own issues 
- and of course its for git not mercurial.

> One thing about cr.openjdk.java.net is that it's usefulness is broader 
> than just hosting webrevs so it would be good to keep it as it's a 
> very handy place to push preliminary webrevs, documents, and other 
> items for discussions on the lists.
>
> Another thing that isn't clear from this mail is whether this is just 
> infrastructure or whether it implies process too. I've no doubt that 
> many areas will want to continue to discuss patches and changes via 
> the mailing lists even if there is a ReviewBoard/equivalent available. 
> One could envisage a discussion about a bug or area of code on the 
> mailing list before the ready-to-be-reviewed changes are published to 
> the review system. You asked about integration with other systems and 
> being able to link to prior discussions in the archives or in the 
> (new) bug database would be useful.
>
> I didn't see command line access mentioned in any of the comments so 
> far. Many of us keep our repositories on servers and it would be be 
> great to be able to run a shell command to publish a change for 
> review. On the review side then having the ability to wget the patch 
> file without authentication would be useful too as sometimes it's 
> easier to just grab the patch and try out the changes.
>
> On the diffs then I think Jon summarized it well and being able to 
> support delta webrevs/equivalent would be very useful as we often go 
> through many iterations where the bulk of the changes are reviewed and 
> we're spinning on a final few issues.
>
> I don't have any comments on the workflow side of this except that 
> folks interested in an area should be able to subscribe so that they 
> get notifications of reviews and discussion for the areas that they 
> are interested in. Also the person seeking a review should be able to 
> accept reviews from folks that he/she didn't originally nominate to 
> review.
>
> -Alan.