Arrgh. Sorry about that. There was some confusion as to which third_party directory those were suppose to go into (we really need to change gcl to base everything from the top of the world). Backing things out shortly. It didn't break nacl's trybots or waterfall because they're less pared down, and probably got thru a try job on mac by chance on the DEPs roll.
I think the right way to avoid this in the future would be a common source size check in both nacl and chrome's PRESUBMIT.py I'll add such a thing shortly. Sorry, I believe I signed off on the original review in the nacl tree. -BradN On Wed, Nov 18, 2009 at 4:29 PM, Evan Martin <e...@chromium.org> wrote: > It seems someone (not blaming them in particular) checked in 300mb of > Windows 64 binaries in the native client tree. > This check-in also seems to have hosed the trybots (they time out > while attempting to fetch this data). > A > > /b/slave/linux/build/src/native_client/src/third_party/mingw-w64/mingw-w64-src_20091116.tar.bz2 > command timed out: 300 seconds without output, killing pid 15342 > elapsedTime=978.505349 > update failed, trying 4 more times after 300 seconds > > > Rather than the obvious rant, I'd like to start a thread on something > constructive: > What can we do to protect our tree from this sort of thing in the future? > - Do we need a trybot for NaCL trunk like we do for WebKit? > - Would presubmit scripts help? (I guess that won't help since > they're in DEPS?) > - Could a style guide that prohibits checking in large binaries help > reviewers catch this? > - Any other ideas? > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
