Changes chrome ebuild to use --jobs 4 for gclient sync.

When syncing my personal tree, I usually use 8. Have we benchmarked it? Is 4 really the inflection point, where adding more parallelism stops really helping?

We may want to leverage MAKEOPTS="-jN" defined in the make.conf since that is a single source of how many parallel jobs to use. It may currently not be set right today, and it may need to be autodetected and setup during seutp_board time.

For a quick fix we could detect number of CPUs from /proc/cpuinfo and then set the right -J flag.

This is for gclient fetching - its almost all network based.

Making this too high will cause a DOS against GIT if we kick off all builders at once.

In talking with folk earlier (forget who but was either Anush or David) I think we settled on four as "gives improvement without killing git server.

I'm aware of what the --jobs flag is for in this case, as I use it almost every day in my development :-)

Also, the chromium repo isn't in git, and it's certainly not in the chromium os git server, so I figure it would make more sense to talk to the chromium infrastructure people. They're the ones who maintain the svn server we'd be syncing against to fetch the chrome source, so they'd probably know better than anush or david in this case.

bulk edit. the block label was set by a bulk edit with the wrong query.

Bulk reassigning chrome build issues to Anush

Commit: ced29a8be8f58308168f56c799ebfcd907183d4c Email: cmasone@chromium.org

Sync chrome source in parallel

We add the --force flag to gclient sync to make it cope with a race condition. The main chrome tree has some stuff checked in under src/third_party/ On Chrome OS, we have a special dep that checks out from a git repo to src/third_party/cros

When doing gclient sync --jobs N, with N>1, the latter will complete before the former, meaning that svn will complain that an unversioned directory exists at src/third_party.

The --force ignores this.

BUG=8859 TEST=emerge chrome with SERVER_SOURCE

Change-Id: Ie69d0b040fb8f7b1830b6875bca56c6775489672

Review URL: http://codereview.chromium.org/5009005

M chromeos-base/chromeos-chrome/chromeos-chrome-9999.ebuild

Bulk edit: Can we please update status and close the bugs if appropriate?

R10->R11

R10->R11

Commit: c0232e95690f17b07868daf08736ddd0244c9429 Email: cmasone@chromium.org

Sync chrome source in parallel

We add the --force flag to gclient sync to make it cope with a race condition. The main chrome tree has some stuff checked in under src/third_party/ On Chrome OS, we have a special dep that checks out from a git repo to src/third_party/cros

When doing gclient sync --jobs N, with N>1, the latter will complete before the former, meaning that svn will complain that an unversioned directory exists at src/third_party.

The --force ignores this.

BUG=8859 TEST=emerge chrome with SERVER_SOURCE

Change-Id: Ie69d0b040fb8f7b1830b6875bca56c6775489672

Review URL: http://codereview.chromium.org/5009005

M chromeos-base/chromeos-chrome/chromeos-chrome-9999.ebuild

Moved to: Issue chromium:191257