On Wed, Jan 26, 2011 at 8:56 PM, Diego Novillo <dnovi...@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.
