Document that rolling clang just got harder.

Document that rolling clang just got harder.

BUG=none
TEST=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=98544

[hans, 2011-08-26 13:27:08]

On 2011/08/26 13:23:58, Nico wrote:

LGTM

If I understand correctly, the problem is that if one updates the DEPS, but
forgets to upload a corresponding tgz, then the bots will be slower because they
need to check out and build Clang (but they won't break?), and anyone who uses
Clang and Goma would be broken?

[Nico, 2011-08-26 13:32:30]

On Fri, Aug 26, 2011 at 1:27 PM,  <hans@chromium.org> wrote:
> On 2011/08/26 13:23:58, Nico wrote:
>
> LGTM
>
> If I understand correctly, the problem is that if one updates the DEPS, but
> forgets to upload a corresponding tgz, then the bots will be slower because
> they need to check out and build Clang (but they won't break?), and anyone who
> uses Clang and Goma would be broken?

(goma makes a "best effort" compiler match – if it doesn't have the
exact right version of a compiler, it will use a compiler with a
similar version)

Possible problems:
1. If one updates DEPS but doesn't upload snapshots to
googledatastorage (but maybe to goma), then the binary hash of the
clang binary on the bots won't match the binary hash of the compiler
in goma. This effectively disables goma's caching.
2. If does everything right but commits the DEPS cl _before_ uploading
the binary to googledatastorage, the bots will build clang themselves
and then never get the binary from googledatastorage because they
already have the right revision (with the same effect as in 1)

Goma wouldn't be broken, it would just use more cpu. (hamaji tells me
that goma without cache is still faster than building without goma)

[commit-bot: I haz the power, 2011-08-26 18:05:14]

Can't apply patch for file DEPS.
While running patch -p1 --forward --force;
patching file DEPS
Hunk #1 FAILED at 35.
1 out of 1 hunk FAILED -- saving rejects to file DEPS.rej