[webkit-dev] Frustrated at inconsiderate behavior

[Adam Barth]

On Wed, Jul 7, 2010 at 7:29 PM, Maciej Stachowiak <mjs at 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