On Wed, Jul 7, 2010 at 7:29 PM, Maciej Stachowiak <m...@apple.com> wrote: > One negative externality is that it > sometimes makes people excessively upset about tree redness, and sometimes > makes them want to fix redness in a way that papers over problems (e.g. by > adding to the skipped list).
If that's the main negative of the commit-queue, we can make it as agressive at landing patches as we want. We started out with a very conservative design, so there are a bunch of knobs to turn: 1) Currently the commit-queue only lands a patch if there were no commits between when it updated its working copy and when the tests finish. This check is to avoid the possibility of another change sneaking in that causes problems (e.g., a change to another file that conflicts semantically). The error case is probably very rare and might not be worth worrying about, but generally mean the commit-queue doesn't land during times when the tree is busy. 2) Currently the commit-queue only lands if it gets a 100% passing run of all the tests. We could instead change it to land if there are no new test failures as a result of applying the patch. This check is to avoid introducing new failures that are masked by existing failures. 3) Currently the commit-queue lands each patch individually. We could instead stack up a bunch of commits in a git branch and build/test them all at once. (Potentially this could be a massive increase in throughput.) We do this to space out the commits so that they generally get separate buildbot runs, which makes failures easier to localize. Adam _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
