Re: Proposal: Improving patch tracking and review using Rietveld

[Richard Guenther <richard dot guenther at gmail dot com>]

On Wed, Jan 26, 2011 at 8:56 PM, Diego Novillo <dnovillo@google.com> wrote:
> At Google we use a code review tool which was open sourced a couple of
> years ago: Rietveld
> (http://code.google.com/appengine/articles/rietveld.html).
>
> The best way of thinking about it is "bugzilla for patches". ?The
> system creates an entry for every patch submitted, provides a web tool
> for manipulating the patch (comments, different views of the diff,
> highlighting, etc) and it also has an email gateway.
>
> We have discussed patch tracking mechanisms in the past, and none so
> far has taken hold. ?The reason why I like Rietveld is that it doesn't
> really matter whether we all switch to using it at once:
>
> 1- Rietveld always send the patch sent to it to gcc-patches@ (provided
> the submitter added gcc-patches to the CC list).
> 2- The whole trail of discussion on the patch also get sent to
> gcc-patches and everyone else is CC'd in it.
> 3- Reviewers do not need to use the web tool to reply to the patch.
> One can simply respond to the e-mail, and it will get added to the
> patch discussion trail.
>
> So, for people who do not want to use the tool, Rietveld will not get
> in the way. ?They can simply respond to the patch as usual, and as
> long as they keep the rietveld email address in the CC list, the patch
> trail will be updated automatically.
>
> At Google we will start using Rietveld to send patches. ?The only
> difference folks will notice is that Rietveld-generated email has some
> extra text.
>
> I have created a wiki page that explains the basics of using Rietveld
> (thanks Jeffrey for the instructions):
> http://gcc.gnu.org/wiki/rietveld
>
> Once again, I'd like to underscore the fact that if a patch submitter
> chooses to use Rietveld for tracking their patches, this should not
> affect in any way the traditional mail-based review. ?All I ask is
> that reviewers maintain the CC and Subject line intact in order to not
> confuse the tool.
>
> Jeffrey, would you mind looking over the instructions I've written to
> make sure they're correct?

Does the tool know when a patch is approved or rejected based on
review e-mail content?  Does it track patches that are related
somehow (either split patch series or updates to patches after
these are requested from a reviewer)?  And how does this integrate
with reviewers not using the tool but old-style e-mails?

Thus, is the tool useful to track stalled patches?  (does it know when
a patch is committed and where?)

Richard.