I agree that this design doesn't solve the problem of writing patches more efficiently. That's not the goal. The goal is to reduce review latency by automating the mechanical parts of the review process.
Adam On Thu, Nov 12, 2009 at 3:38 PM, Ojan Vafai <[email protected]> wrote: > This approach doesn't lend itself as well to trying patches before putting > them up for review. Specifically, I want to be able to try patches without > spamming everyone with bugzilla mail. This is solvable in this > bugzilla-based approach, but it doesn't lend itself to this as > naturally, e.g. presumably there's a way to tell bugzilla not to send mail > for a given comment. > > Also, it would be great if the commit-queue, try-server, whatever, had a UI > like the buildbot waterfall. There's a couple advantages: > 1. Can see the stdio as the tests run and get better information about why > it failed. > 2. Can grab layout test results from the try servers. This would reduce the > need/occurence of committing Mac expectations and then cleaning up other > platforms post commit. > Ojan _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
