OpenJDK Code review system - Request for use cases and requirements
spoole at linux.vnet.ibm.com
Mon Apr 18 08:11:12 PDT 2011
On 18/04/11 11:32, Alan Bateman wrote:
> Mohan Pakkurti wrote:
>> 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?
> 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
More information about the web-discuss