Patch path filtering script.

Patch path filtering script.

A script that makes it possible to filter out files from a patch
using paths, which can be useful for some trybot situations.

It is used if additional flags are passed to the apply_svn_patch.py script.
This is required in order to make https://codereview.chromium.org/75163006/
possible.

TEST=local testing and unit tests.
BUG=312827
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=240099

[kjellander_chromium, 2013-10-29 16:19:21]

Here's the script I was talking about. It's a piece I think I'll need for the
complex Android APK building trybot I'm working on creating a recipe for.

[iannucci, 2013-10-29 17:15:02]

very high-level comments.

https://codereview.chromium.org/27575002/diff/22001/scripts/slave/patch_path_...
File scripts/slave/patch_path_filter.py (right):

https://codereview.chromium.org/27575002/diff/22001/scripts/slave/patch_path_...
scripts/slave/patch_path_filter.py:45: '^\+{3}\s(.*?)$')
I would use a raw string here (i.e. r' stuff '). The only escape char which
works is r'\''

And although I think the -{3} is cute, '---' is probably better :)

Also, you'll want to make sure you test with weird patches, like moving/copying
files, mode changes (executable v. not), etc.

I think there is already some diff-parsing code in depot_tools that's used by
apply_issue.py. It may be worth investigating and sharing?

https://codereview.chromium.org/27575002/diff/22001/scripts/slave/unittests/p...
File scripts/slave/unittests/patch_path_filter_test.py (right):

https://codereview.chromium.org/27575002/diff/22001/scripts/slave/unittests/p...
scripts/slave/unittests/patch_path_filter_test.py:119: unittest.main()
I would definitely consider formulating the test as a series of inputs (patches
in a folder), and then committing the outputs (filtered patches in a folder).

Then it would be trivial to add new test cases, especially when we find a patch
that doesn't work (i.e. you drop the bad patch in the inputs, train the outputs,
and then fix the code until the output is good).

[kjellander_chromium, 2013-11-07 12:55:25]

Robert: I agree with your comments and I looked around in the
depot_tools/patch.py. It looks very complete and has great test coverage. 
Before I spend more time on refactoring this (and possible required changes in
patch.py) I'd like to get input from maruel@ on this.

[M-A Ruel, 2013-11-07 13:04:47]

On 2013/11/07 12:55:25, Henrik Kjellander wrote:
> Robert: I agree with your comments and I looked around in the
> depot_tools/patch.py. It looks very complete and has great test coverage. 
> Before I spend more time on refactoring this (and possible required changes in
> patch.py) I'd like to get input from maruel@ on this.

Just so I understand, this is exclusively for svn triggered try jobs with no
expectation to support rietveld ever?

[kjellander_chromium, 2013-11-07 14:17:39]

On 2013/11/07 13:04:47, M-A Ruel wrote:
> On 2013/11/07 12:55:25, Henrik Kjellander wrote:
> > Robert: I agree with your comments and I looked around in the
> > depot_tools/patch.py. It looks very complete and has great test coverage. 
> > Before I spend more time on refactoring this (and possible required changes
in
> > patch.py) I'd like to get input from maruel@ on this.
> 
> Just so I understand, this is exclusively for svn triggered try jobs with no
> expectation to support rietveld ever?

ever is a strong word. I'd say for now it'll only be used to support our WebRTC
try server. But if we would move into Chromium's Rietveld instance in the future
to get Try server integration, it would be nice to still be able to try
WebRTC-standalone patches directly from Rietveld. We don't see a large enough
need to invest in such a migration today though.

[kjellander_chromium, 2013-11-20 14:44:35]

Mike, would you mind taking a look at this too? I think I'll need help to
navigate the depot_tools/patch.py and maruel@ said you're working in this area
too.

[ghost stip (do not use), 2013-11-20 18:48:30]

I recall discussing this when you were in MTV. Can you remind me the scenario
where this is useful again?

[kjellander_chromium, 2013-11-20 18:51:38]

On 2013/11/20 18:48:30, stip wrote:
> I recall discussing this when you were in MTV. Can you remind me the scenario
> where this is useful again?

It's for getting try patches generated from a WebRTC checkout shall be possible
to apply both to a normal WebRTC try slave (using a plain WebRTC checkout) but
also our somewhat complicated Android APK builders that uses a Chromium checkout
(where we want to patch only the src/third_party/webrtc code). See
https://codereview.chromium.org/75163006/ for more details.

[ghost stip (do not use), 2013-11-21 10:00:09]

some thoughts after talking to Henrik offline:

depot_tools/patch.py looks to be a fully-featured patch parser. it would be nice
to use this, however:

a) we don't really have stuff in build/ that imports from depot_tools, and doing
so would set up a circular dependency

b) putting this parsing logic in depot_tools itself would make it generally
useful, but then work would have to be done to make
scripts/slave/apply_svn_patch.py work with that (knowing the location of
depot_tools to call the filter script).

because this patch solves a direct problem, I'm in favor of the current location
and design. if we find it to be more generally useful, we can look into
promoting it to depot_tools and perhaps using patch.py

[M-A Ruel, 2013-11-21 14:58:27]

On 2013/11/21 10:00:09, stip wrote:
> some thoughts after talking to Henrik offline:
> 
> depot_tools/patch.py looks to be a fully-featured patch parser. it would be
nice
> to use this, however:
> 
> a) we don't really have stuff in build/ that imports from depot_tools, and
doing
> so would set up a circular dependency
> 
> b) putting this parsing logic in depot_tools itself would make it generally
> useful, but then work would have to be done to make
> scripts/slave/apply_svn_patch.py work with that (knowing the location of
> depot_tools to call the filter script).
> 
> because this patch solves a direct problem, I'm in favor of the current
location
> and design. if we find it to be more generally useful, we can look into
> promoting it to depot_tools and perhaps using patch.py

I usually solve this problem with third_party/depot_tools/ with a proper README.
It has the caveat of copies proliferation, but as long as the README is properly
kept up to date when the rolls, it's fine in practice. It has the downside of
using older copies, e.g. upgrades are manual but it hasn't been a big deal in
practice. Case in point: Rietveld's upload.py in depot_tools.

[kjellander_chromium, 2013-11-26 22:11:25]

Finally ready for another round (Robert).

I'm now using depot tools' patch.py as suggested by maruel@, by creating a copy
of it in third_party. This makes the only parsing needed in patch_path_filter.py
to be the splitting of a patch set into separate patch entries.

This is partially handled in depot_tools/gclient_scm.py but since that code
relies on executing the actual git/svn command and filtering the output, I
thought it was better to implement that parsing here, than attempting to
refactor out that stuff.

I suspect you might want more unit tests, but I wanted to get this going first,
so please take a look.

https://codereview.chromium.org/27575002/diff/22001/scripts/slave/patch_path_...
File scripts/slave/patch_path_filter.py (right):

https://codereview.chromium.org/27575002/diff/22001/scripts/slave/patch_path_...
scripts/slave/patch_path_filter.py:45: '^\+{3}\s(.*?)$')
On 2013/10/29 17:15:02, iannucci wrote:
> I would use a raw string here (i.e. r' stuff '). The only escape char which
> works is r'\''

This is remade in Patch set #3.

> 
> And although I think the -{3} is cute, '---' is probably better :)

No longer needed since I use patch.py's parsing now.

> Also, you'll want to make sure you test with weird patches, like
moving/copying
> files, mode changes (executable v. not), etc.

I'm trusting patch.py is heavily tested already.

> I think there is already some diff-parsing code in depot_tools that's used by
> apply_issue.py. It may be worth investigating and sharing?

Patch Set #3 is now using depot tools patch.py and the only thing that is parsed
in here is the splitting of the patch set into patches.

https://codereview.chromium.org/27575002/diff/22001/scripts/slave/unittests/p...
File scripts/slave/unittests/patch_path_filter_test.py (right):

https://codereview.chromium.org/27575002/diff/22001/scripts/slave/unittests/p...
scripts/slave/unittests/patch_path_filter_test.py:119: unittest.main()
On 2013/10/29 17:15:02, iannucci wrote:
> I would definitely consider formulating the test as a series of inputs
(patches
> in a folder), and then committing the outputs (filtered patches in a folder).
> Then it would be trivial to add new test cases, especially when we find a
patch
> that doesn't work (i.e. you drop the bad patch in the inputs, train the
outputs,
> and then fix the code until the output is good).

That's a good idea, but as maruel@ said, it's better to add depot tools patch.py
as a third party component and rely on its parsing instead. It feels safer.

[kjellander_chromium, 2013-11-26 22:12:09]

On 2013/11/21 14:58:27, M-A Ruel wrote:
> On 2013/11/21 10:00:09, stip wrote:
> > some thoughts after talking to Henrik offline:
> > 
> > depot_tools/patch.py looks to be a fully-featured patch parser. it would be
> nice
> > to use this, however:
> > 
> > a) we don't really have stuff in build/ that imports from depot_tools, and
> doing
> > so would set up a circular dependency
> > 
> > b) putting this parsing logic in depot_tools itself would make it generally
> > useful, but then work would have to be done to make
> > scripts/slave/apply_svn_patch.py work with that (knowing the location of
> > depot_tools to call the filter script).
> > 
> > because this patch solves a direct problem, I'm in favor of the current
> location
> > and design. if we find it to be more generally useful, we can look into
> > promoting it to depot_tools and perhaps using patch.py
> 
> I usually solve this problem with third_party/depot_tools/ with a proper
README.
> It has the caveat of copies proliferation, but as long as the README is
properly
> kept up to date when the rolls, it's fine in practice. It has the downside of
> using older copies, e.g. upgrades are manual but it hasn't been a big deal in
> practice. Case in point: Rietveld's upload.py in depot_tools.

Thanks for the suggestion! I used this approach in patch set #3 now and it seems
to work great.

[iannucci, 2013-12-05 21:40:56]

https://chromiumcodereview.appspot.com/27575002/diff/272001/scripts/slave/app...
File scripts/slave/apply_svn_patch.py (right):

https://chromiumcodereview.appspot.com/27575002/diff/272001/scripts/slave/app...
scripts/slave/apply_svn_patch.py:18: help=('A script that filter out contents of
a patch. The '
s/filter/filters/

Should also mention that the script MUST be python.

I would also make a point of passing -r, -p, and --strip-level directly through
to the filter script as the first arguments.

https://chromiumcodereview.appspot.com/27575002/diff/272001/scripts/slave/app...
scripts/slave/apply_svn_patch.py:23: 'path filter script to use this).'))
What about:

apply_svn_patch.py ... --path-filter-script cool.py -- -f something -o "special
option" ...

Then anything after the '--' gets appended to the path-filter-script's command
line, and we don't hard-code the '-f' below. Then the filter Popen could be:

index_of_dashes = sys.argv.index('--') if '--' in sys.argv else None
extra_args = ['--'] + sys.argv[index_of_dashes:] if index_of_dashes else []
Popen([sys.executable, options.path_filter_script,
 '-p', options.patch_url,
 '-r', options.root_dir,
 '--strip-level', options.strip_level] + extra_args, ...)

https://chromiumcodereview.appspot.com/27575002/diff/272001/scripts/slave/uni...
File scripts/slave/unittests/patch_path_filter_test.py (right):

https://chromiumcodereview.appspot.com/27575002/diff/272001/scripts/slave/uni...
scripts/slave/unittests/patch_path_filter_test.py:58: unittest.main()
What do you think about a folder full of:
  tests/test_case_name.patch
  tests/test_case_name.args
  tests/test_case_name.output

?

Then adding a test case for gnarly patch is just dropping the patch and args in,
and running the test to get the output, and checking test results is just
running diff?

https://chromiumcodereview.appspot.com/27575002/diff/272001/third_party/depot...
File third_party/depot_tools/patch.py (right):

https://chromiumcodereview.appspot.com/27575002/diff/272001/third_party/depot...
third_party/depot_tools/patch.py:5: """Utility functions to handle patches."""
holy snapdragons! I don't think we need this stuff to be committed since we're
guaranteed that depot_tools is on the machine already at ../depot_tools.

The " 'right' " thing is to manipulate sys.path so you can import patch.py
directly. Yeah, it's gross. No it's not really 'good', but it's what we already
rely on. It's on the list of things to fix. I think it's a bit less bad than
forking patch.py though.

[kjellander_chromium, 2013-12-10 20:46:02]

iannucci@: PTAL!

Puh! A lot of work goes into this one. At least now I'm getting pretty confident
with the depot_tools stuff and how Git/Svn patches are made up (and the tweaks
maruel@ has added to compensate for missing pieces). 

I've now learned that in depot_tools/third_party/upload.py all Git patches being
uploaded gets “Index:” added to the beginning of it (similar to a Subversion
patch). This heavily simplifies things as my filter script only attempts to
support patches created from try jobs with depot tools.

I've extended the unit tests quite a bit with patch files on disk as iannucci@
suggested.
The unit tests has been run on both Mac and Linux. Unfortunately they take a bit
of time to run now (0.5s on my MacBook Pro).

I've also performed local tests on a chromium checkout (standing one level above
src/ as the bots do), running commands like this:

$ $HOME/buildbot/build/scripts/slave/apply_svn_patch.py -p
file:///my/local-svn-repo/git_patch2.patch -r src/third_party/webrtc
--filter-script=$HOME/buildbot/build/scripts/slave/patch_path_filter.py
--strip-level=1 -- --path-filter=src/third_party/webrtc/webrtc/

I checked in one of the patches into a local Subversion server and used the
file:///my/local-svn-repo/git_patch2.patch URL to make it as close to a real
situation as possible.
The path-filter argument with dual webrtc/ dirs may look strange, but it's
because of how the levels are added when a patch is created in a WebRTC
standalone checkout (and we want to make sure src/third_party/webrtc is the root
so the patch won't create files outside of that dir). The --strip-level=1 will
take care of eliminating one level and make it all apply.

https://codereview.chromium.org/27575002/diff/272001/scripts/slave/apply_svn_...
File scripts/slave/apply_svn_patch.py (right):

https://codereview.chromium.org/27575002/diff/272001/scripts/slave/apply_svn_...
scripts/slave/apply_svn_patch.py:18: help=('A script that filter out contents of
a patch. The '
On 2013/12/05 21:40:57, iannucci wrote:
> s/filter/filters/
I rephrased so it shouldn't be needed now. I also renamed to --filter-script to
make it a bit more generic.

> Should also mention that the script MUST be python.
Done.

> I would also make a point of passing -r, -p, and --strip-level directly
through
> to the filter script as the first arguments.

I think it would be annoying to have to support arguments that are not used, so
I disagree there. However I need the --root-dir in my case, so that one is
added. Additional flags can be passed using -- --flag

https://codereview.chromium.org/27575002/diff/272001/scripts/slave/apply_svn_...
scripts/slave/apply_svn_patch.py:23: 'path filter script to use this).'))
On 2013/12/05 21:40:57, iannucci wrote:
> What about:
> 
> apply_svn_patch.py ... --path-filter-script cool.py -- -f something -o
"special
> option" ...
> 
> Then anything after the '--' gets appended to the path-filter-script's command
> line, and we don't hard-code the '-f' below. Then the filter Popen could be:
> 
> index_of_dashes = sys.argv.index('--') if '--' in sys.argv else None
> extra_args = ['--'] + sys.argv[index_of_dashes:] if index_of_dashes else []
> Popen([sys.executable, options.path_filter_script,
>  '-p', options.patch_url,
>  '-r', options.root_dir,
>  '--strip-level', options.strip_level] + extra_args, ...)

I guess this makes perfect sense for --path-filter since that's only used by the
path-filter-script. However --root-dir is used both by it and the patch command.
I removed --path-filter from this file and made it pass only the --root-dir now.

The -- terminator will have to be used to pass the --path-filter flag (and
possible other flags to the script), but the implementation is much simpler as
you can see.

https://codereview.chromium.org/27575002/diff/272001/scripts/slave/patch_path...
File scripts/slave/patch_path_filter.py (right):

https://codereview.chromium.org/27575002/diff/272001/scripts/slave/patch_path...
scripts/slave/patch_path_filter.py:82: is_git = any(l.startswith(_GIT_PREFIX)
for l in patch_contents.splitlines())
Turns out this is actually not needed if we assume we're working with only depot
tools generated patches (that all have Index: in the beginning of each patch
chunk)

https://codereview.chromium.org/27575002/diff/272001/scripts/slave/unittests/...
File scripts/slave/unittests/patch_path_filter_test.py (right):

https://codereview.chromium.org/27575002/diff/272001/scripts/slave/unittests/...
scripts/slave/unittests/patch_path_filter_test.py:58: unittest.main()
On 2013/12/05 21:40:57, iannucci wrote:
> What do you think about a folder full of:
>   tests/test_case_name.patch
>   tests/test_case_name.args
>   tests/test_case_name.output
> 
> ?
> 
> Then adding a test case for gnarly patch is just dropping the patch and args
in,
> and running the test to get the output, and checking test results is just
> running diff?

I agree with you. I didn't feel confident that the code was covering all cases
yet, so I worked on  implemented this combined with some additional refactoring
after discovering that upload.py actually always adds Index: (even to Git
patches)

https://codereview.chromium.org/27575002/diff/272001/third_party/depot_tools/...
File third_party/depot_tools/patch.py (right):

https://codereview.chromium.org/27575002/diff/272001/third_party/depot_tools/...
third_party/depot_tools/patch.py:5: """Utility functions to handle patches."""
On 2013/12/05 21:40:57, iannucci wrote:
> holy snapdragons! I don't think we need this stuff to be committed since we're
> guaranteed that depot_tools is on the machine already at ../depot_tools.
> 
> The " 'right' " thing is to manipulate sys.path so you can import patch.py
> directly. Yeah, it's gross. No it's not really 'good', but it's what we
already
> rely on. It's on the list of things to fix. I think it's a bit less bad than
> forking patch.py though.

I don't agree this is that bad, in fact it's what maruel@ suggested and does for
the upload.py in depot_tools/third_party (it's a copy of
https://code.google.com/p/rietveld/source/browse/upload.py).
Since depot_tools is auto-updated quite often, this is a much safer (although
uglier) 
way to add a dependency to that code.

If we rely on ToT depot_tools in this script, this usage may instantly break as
soon
someone refactors patch.py in depot_tools. And the author doing that won't be
able to
detect the breakage in advance by running the depot_tools' tests.

https://codereview.chromium.org/27575002/diff/312001/scripts/slave/patch_path...
File scripts/slave/patch_path_filter.py (right):

https://codereview.chromium.org/27575002/diff/312001/scripts/slave/patch_path...
scripts/slave/patch_path_filter.py:60: def
convert_to_patch_compatible_diff(filename, patch_data):
When doing testing on actual checkouts with the apply_svn_patch.py script, I
realized that that script probably only ever worked with Subversion patches. I
always thought the name referred to where the patch comes _from_ (i.e. the try
servers' Subversion queue repo). Either way this makes my case support both
Subversion and Git.

I guess I could have used depot_tools's apply_issue.py and checkout.py's
{Svn,Git}Checkout.apply_patch functions too, but I think it would complicate
this even further.

[iannucci, 2013-12-10 21:32:23]

lgtm :)

https://chromiumcodereview.appspot.com/27575002/diff/272001/third_party/depot...
File third_party/depot_tools/patch.py (right):

https://chromiumcodereview.appspot.com/27575002/diff/272001/third_party/depot...
third_party/depot_tools/patch.py:5: """Utility functions to handle patches."""
On 2013/12/10 20:46:02, Henrik Kjellander wrote:
> On 2013/12/05 21:40:57, iannucci wrote:
> > holy snapdragons! I don't think we need this stuff to be committed since
we're
> > guaranteed that depot_tools is on the machine already at ../depot_tools.
> > 
> > The " 'right' " thing is to manipulate sys.path so you can import patch.py
> > directly. Yeah, it's gross. No it's not really 'good', but it's what we
> already
> > rely on. It's on the list of things to fix. I think it's a bit less bad than
> > forking patch.py though.
> 
> I don't agree this is that bad, in fact it's what maruel@ suggested and does
for
> the upload.py in depot_tools/third_party (it's a copy of
> https://code.google.com/p/rietveld/source/browse/upload.py).
> Since depot_tools is auto-updated quite often, this is a much safer (although
> uglier) 
> way to add a dependency to that code.
> 
> If we rely on ToT depot_tools in this script, this usage may instantly break
as
> soon
> someone refactors patch.py in depot_tools. And the author doing that won't be
> able to
> detect the breakage in advance by running the depot_tools' tests.

Yeah... frankly, they're both bad. Having proper deps would be better. But we
can't have that at the moment :)

https://chromiumcodereview.appspot.com/27575002/diff/312001/scripts/slave/pat...
File scripts/slave/patch_path_filter.py (right):

https://chromiumcodereview.appspot.com/27575002/diff/312001/scripts/slave/pat...
scripts/slave/patch_path_filter.py:35: if ((line.startswith('Index:') or
line.startswith('Property changes on:'))
FYI, you can do 

line.startswith(('Index:', 'Property changes on:'))

http://docs.python.org/2/library/stdtypes.html#str.startswith

https://chromiumcodereview.appspot.com/27575002/diff/312001/scripts/slave/pat...
scripts/slave/patch_path_filter.py:45: filename_regex = re.compile(r'^.*:
([^\t]+).*\n$')
I would put this up in the global scope as FILENAME_REGEX. Though I'm not sure
it matters. The re module does do regex caching of some sort, I think.

https://chromiumcodereview.appspot.com/27575002/diff/312001/scripts/slave/pat...
scripts/slave/patch_path_filter.py:64: compatible with the standard patch
program.
you could also just pass -p1 to patch.

https://chromiumcodereview.appspot.com/27575002/diff/312001/scripts/slave/pat...
scripts/slave/patch_path_filter.py:70: if line.startswith('+++'):
elif? though obviously both won't hit, but it may be clearer to read.

https://chromiumcodereview.appspot.com/27575002/diff/312001/scripts/slave/uni...
File scripts/slave/unittests/patch_path_filter_test.py (right):

https://chromiumcodereview.appspot.com/27575002/diff/312001/scripts/slave/uni...
scripts/slave/unittests/patch_path_filter_test.py:121: unittest.main()
We really need to find a replacement for unittest which parallelizes tests by
default :(. I had to bend over backwards to parallelize some of the recipes
tests, and they're still not as parallelized as they could be :/

[commit-bot: I haz the power, 2013-12-11 10:01:43]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/kjellander@chromium.org/27575002/312001

[kjellander_chromium, 2013-12-11 13:31:31]

Fixed the last nits, but kept my conversion of the Git patches to make them
usable by patch.

https://codereview.chromium.org/27575002/diff/312001/scripts/slave/patch_path...
File scripts/slave/patch_path_filter.py (right):

https://codereview.chromium.org/27575002/diff/312001/scripts/slave/patch_path...
scripts/slave/patch_path_filter.py:35: if ((line.startswith('Index:') or
line.startswith('Property changes on:'))
On 2013/12/10 21:32:23, iannucci wrote:
> FYI, you can do 
> 
> line.startswith(('Index:', 'Property changes on:'))
> 
> http://docs.python.org/2/library/stdtypes.html#str.startswith

Thanks, fixed.

https://codereview.chromium.org/27575002/diff/312001/scripts/slave/patch_path...
scripts/slave/patch_path_filter.py:45: filename_regex = re.compile(r'^.*:
([^\t]+).*\n$')
On 2013/12/10 21:32:23, iannucci wrote:
> I would put this up in the global scope as FILENAME_REGEX. Though I'm not sure
> it matters. The re module does do regex caching of some sort, I think.

Done.

https://codereview.chromium.org/27575002/diff/312001/scripts/slave/patch_path...
scripts/slave/patch_path_filter.py:64: compatible with the standard patch
program.
On 2013/12/10 21:32:23, iannucci wrote:
> you could also just pass -p1 to patch.

I could if I knew when invoking the patch program which kind of patch it is.
Unfortunately that's not easily found out without first reading all the output
from the svn cat process into a string in apply_svn_patch.py. Then I could
increment the strip-level number by one for Git patches. I think this is easier,
although not very elegant.

https://codereview.chromium.org/27575002/diff/312001/scripts/slave/patch_path...
scripts/slave/patch_path_filter.py:70: if line.startswith('+++'):
On 2013/12/10 21:32:23, iannucci wrote:
> elif? though obviously both won't hit, but it may be clearer to read.

Done.

https://codereview.chromium.org/27575002/diff/312001/scripts/slave/unittests/...
File scripts/slave/unittests/patch_path_filter_test.py (right):

https://codereview.chromium.org/27575002/diff/312001/scripts/slave/unittests/...
scripts/slave/unittests/patch_path_filter_test.py:121: unittest.main()
On 2013/12/10 21:32:23, iannucci wrote:
> We really need to find a replacement for unittest which parallelizes tests by
> default :(. I had to bend over backwards to parallelize some of the recipes
> tests, and they're still not as parallelized as they could be :/

I agree, but it's outside my expertise/time prioritization right now. I'll be
happy to help out exploring such solutions though.

[commit-bot: I haz the power, 2013-12-11 13:31:46]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/kjellander@chromium.org/27575002/332001

[commit-bot: I haz the power, 2013-12-11 13:33:29]

Change committed as 240099