Pepper: Log in UMA when an interface is used.

Pepper: Log in UMA when an interface is used.

We'd like to know what versions of our interfaces are used by end users. This
change logs usage of PPB interfaces for out-of-process plugins the first time
that get_interface<>() is called for a given interface and version.

I tested this change by loading some plugin examples and checking the
about:histograms page.

BUG=111542
R=asvitkine@chromium.org, jschuh@chromium.org, yzshen@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=249007

[yzshen1, 2014-01-30 18:15:45]

LGTM with a nit.

Thanks!

https://codereview.chromium.org/141523010/diff/1/tools/metrics/histograms/his...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/141523010/diff/1/tools/metrics/histograms/his...
tools/metrics/histograms/histograms.xml:12717: +    The number of times a Pepper
interface version has been retrieved for usage.
I think it is good to be more clear about how the number is counted. As you said
in the description: "This change logs usage of PPB interfaces for out-of-process
plugins the first time that get_interface<>() is called for a given interface
and version."

[teravest, 2014-01-30 18:22:19]

Changed to:
    The number of times an out-of-process plugin has loaded a PPB interface
    version for the first time.

Thanks!

On Thu, Jan 30, 2014 at 11:15 AM,  <yzshen@chromium.org> wrote:
> LGTM with a nit.
>
> Thanks!
>
>
>
https://codereview.chromium.org/141523010/diff/1/tools/metrics/histograms/his...
> File tools/metrics/histograms/histograms.xml (right):
>
>
https://codereview.chromium.org/141523010/diff/1/tools/metrics/histograms/his...
> tools/metrics/histograms/histograms.xml:12717: +    The number of times
>
> a Pepper interface version has been retrieved for usage.
> I think it is good to be more clear about how the number is counted. As
> you said in the description: "This change logs usage of PPB interfaces
>
> for out-of-process plugins the first time that get_interface<>() is
> called for a given interface and version."
>
> https://codereview.chromium.org/141523010/

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[teravest, 2014-01-30 18:23:19]

+jar for tools/metrics/histograms/histograms.xml
+jschuh for ppapi/proxy/ppapi_messages.h

[yzshen, 2014-01-30 18:25:06]

It may be easier to understand:
The number of plugin processes that has loaded a PPB interface version.

Oh, I forgot to ask: do we log the total number of plugin processes? That
might be also a useful number. (No need to change this CL to add that.)


On Thu, Jan 30, 2014 at 10:21 AM, Justin TerAvest <teravest@chromium.org>wrote:

> Changed to:
>     The number of times an out-of-process plugin has loaded a PPB interface
>     version for the first time.
>
> Thanks!
>
> On Thu, Jan 30, 2014 at 11:15 AM,  <yzshen@chromium.org> wrote:
> > LGTM with a nit.
> >
> > Thanks!
> >
> >
> >
>
https://codereview.chromium.org/141523010/diff/1/tools/metrics/histograms/his...
> > File tools/metrics/histograms/histograms.xml (right):
> >
> >
>
https://codereview.chromium.org/141523010/diff/1/tools/metrics/histograms/his...
> > tools/metrics/histograms/histograms.xml:12717: +    The number of times
> >
> > a Pepper interface version has been retrieved for usage.
> > I think it is good to be more clear about how the number is counted. As
> > you said in the description: "This change logs usage of PPB interfaces
> >
> > for out-of-process plugins the first time that get_interface<>() is
> > called for a given interface and version."
> >
> > https://codereview.chromium.org/141523010/
>



-- 
Best regards,
Yuzhu Shen.

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[teravest, 2014-01-30 18:27:38]

On Thu, Jan 30, 2014 at 11:25 AM, Yuzhu Shen <yzshen@google.com> wrote:
> It may be easier to understand:
> The number of plugin processes that has loaded a PPB interface version.

Done.

>
> Oh, I forgot to ask: do we log the total number of plugin processes? That
> might be also a useful number. (No need to change this CL to add that.)

I don't believe so, but I think that should be easy to add. I'd rather
do it in another change, though.

>
>
> On Thu, Jan 30, 2014 at 10:21 AM, Justin TerAvest <teravest@chromium.org>
> wrote:
>>
>> Changed to:
>>     The number of times an out-of-process plugin has loaded a PPB
>> interface
>>     version for the first time.
>>
>> Thanks!
>>
>> On Thu, Jan 30, 2014 at 11:15 AM,  <yzshen@chromium.org> wrote:
>> > LGTM with a nit.
>> >
>> > Thanks!
>> >
>> >
>> >
>> >
https://codereview.chromium.org/141523010/diff/1/tools/metrics/histograms/his...
>> > File tools/metrics/histograms/histograms.xml (right):
>> >
>> >
>> >
https://codereview.chromium.org/141523010/diff/1/tools/metrics/histograms/his...
>> > tools/metrics/histograms/histograms.xml:12717: +    The number of times
>> >
>> > a Pepper interface version has been retrieved for usage.
>> > I think it is good to be more clear about how the number is counted. As
>> > you said in the description: "This change logs usage of PPB interfaces
>> >
>> > for out-of-process plugins the first time that get_interface<>() is
>> > called for a given interface and version."
>> >
>> > https://codereview.chromium.org/141523010/
>
>
>
>
> --
> Best regards,
> Yuzhu Shen.

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[teravest, 2014-01-30 21:24:58]

-jar +asvitkine for tools/metrics/...

[jschuh, 2014-01-31 13:17:24]

ipc security lgtm.

[Alexei Svitkine (slow), 2014-01-31 17:49:04]

https://codereview.chromium.org/141523010/diff/30001/ppapi/proxy/interface_li...
File ppapi/proxy/interface_list.cc (right):

https://codereview.chromium.org/141523010/diff/30001/ppapi/proxy/interface_li...
ppapi/proxy/interface_list.cc:331: int hash =
bit_cast<int>(base::Hash(name.c_str(), name.size()));
What is |name| in this case? Is there a list of valid possibilities somewhere?

[teravest, 2014-02-03 15:36:54]

https://codereview.chromium.org/141523010/diff/30001/ppapi/proxy/interface_li...
File ppapi/proxy/interface_list.cc (right):

https://codereview.chromium.org/141523010/diff/30001/ppapi/proxy/interface_li...
ppapi/proxy/interface_list.cc:331: int hash =
bit_cast<int>(base::Hash(name.c_str(), name.size()));
On 2014/01/31 17:49:04, Alexei Svitkine wrote:
> What is |name| in this case? Is there a list of valid possibilities somewhere?

There's a list of valid possibilities, but it's spread across a few files.

It would include the first argument to all the calls to AddPPB in this file,
plus the first argument to the PROXIED_IFACE macro used in the header files
listed in lines 183-205.

[Alexei Svitkine (slow), 2014-02-03 19:25:10]

https://codereview.chromium.org/141523010/diff/30001/ppapi/proxy/interface_li...
File ppapi/proxy/interface_list.cc (right):

https://codereview.chromium.org/141523010/diff/30001/ppapi/proxy/interface_li...
ppapi/proxy/interface_list.cc:331: int hash =
bit_cast<int>(base::Hash(name.c_str(), name.size()));
On 2014/02/03 15:36:55, teravest wrote:
> On 2014/01/31 17:49:04, Alexei Svitkine wrote:
> > What is |name| in this case? Is there a list of valid possibilities
somewhere?
> 
> There's a list of valid possibilities, but it's spread across a few files.
> 
> It would include the first argument to all the calls to AddPPB in this file,
> plus the first argument to the PROXIED_IFACE macro used in the header files
> listed in lines 183-205.

I think you should make an effort to enumerate these and include them as an enum
in histograms.xml. And also document the APIs that these can be passed to,
mentioning that if a new one is added, histograms.xml should be updated.

That way, the data on the dashboard can be meaningful, rather than a bunch of
undecipherable hashes.

[teravest, 2014-02-03 20:13:10]

I'll give that a shot. Is the syntax for sparse histograms the same as
for normal enum-based histograms?

I'm guessing an example would look like this?
<enum name="..." type="int">
  <int value="1144571655" label="Interface;1.0"/>
  more ints....
</enum>



On Mon, Feb 3, 2014 at 12:25 PM,  <asvitkine@chromium.org> wrote:
>
>
https://codereview.chromium.org/141523010/diff/30001/ppapi/proxy/interface_li...
> File ppapi/proxy/interface_list.cc (right):
>
>
https://codereview.chromium.org/141523010/diff/30001/ppapi/proxy/interface_li...
> ppapi/proxy/interface_list.cc:331: int hash =
> bit_cast<int>(base::Hash(name.c_str(), name.size()));
> On 2014/02/03 15:36:55, teravest wrote:
>>
>> On 2014/01/31 17:49:04, Alexei Svitkine wrote:
>> > What is |name| in this case? Is there a list of valid possibilities
>
> somewhere?
>
>> There's a list of valid possibilities, but it's spread across a few
>
> files.
>
>> It would include the first argument to all the calls to AddPPB in this
>
> file,
>>
>> plus the first argument to the PROXIED_IFACE macro used in the header
>
> files
>>
>> listed in lines 183-205.
>
>
> I think you should make an effort to enumerate these and include them as
> an enum in histograms.xml. And also document the APIs that these can be
> passed to, mentioning that if a new one is added, histograms.xml should
> be updated.
>
> That way, the data on the dashboard can be meaningful, rather than a
> bunch of undecipherable hashes.
>
> https://codereview.chromium.org/141523010/

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Alexei Svitkine (slow), 2014-02-03 20:14:35]

Yes, the syntax is the same.


On Mon, Feb 3, 2014 at 3:12 PM, Justin TerAvest <teravest@chromium.org>wrote:

> I'll give that a shot. Is the syntax for sparse histograms the same as
> for normal enum-based histograms?
>
> I'm guessing an example would look like this?
> <enum name="..." type="int">
>   <int value="1144571655" label="Interface;1.0"/>
>   more ints....
> </enum>
>
>
>
> On Mon, Feb 3, 2014 at 12:25 PM,  <asvitkine@chromium.org> wrote:
> >
> >
>
https://codereview.chromium.org/141523010/diff/30001/ppapi/proxy/interface_li...
> > File ppapi/proxy/interface_list.cc (right):
> >
> >
>
https://codereview.chromium.org/141523010/diff/30001/ppapi/proxy/interface_li...
> > ppapi/proxy/interface_list.cc:331: int hash =
> > bit_cast<int>(base::Hash(name.c_str(), name.size()));
> > On 2014/02/03 15:36:55, teravest wrote:
> >>
> >> On 2014/01/31 17:49:04, Alexei Svitkine wrote:
> >> > What is |name| in this case? Is there a list of valid possibilities
> >
> > somewhere?
> >
> >> There's a list of valid possibilities, but it's spread across a few
> >
> > files.
> >
> >> It would include the first argument to all the calls to AddPPB in this
> >
> > file,
> >>
> >> plus the first argument to the PROXIED_IFACE macro used in the header
> >
> > files
> >>
> >> listed in lines 183-205.
> >
> >
> > I think you should make an effort to enumerate these and include them as
> > an enum in histograms.xml. And also document the APIs that these can be
> > passed to, mentioning that if a new one is added, histograms.xml should
> > be updated.
> >
> > That way, the data on the dashboard can be meaningful, rather than a
> > bunch of undecipherable hashes.
> >
> > https://codereview.chromium.org/141523010/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[teravest, 2014-02-03 23:12:21]

Alexei,
Hash values are provided in histograms.xml now. I tested locally to make sure
they match.

Yuzhu,
Can you take a look at ppapi/tools and make sure that looks ok with you?
I'll add some documentation to the web page for adding pepper interfaces as
well.

[yzshen1, 2014-02-03 23:28:55]

https://codereview.chromium.org/141523010/diff/120001/ppapi/thunk/interfaces_...
File ppapi/thunk/interfaces_ppb_public_stable.h (right):

https://codereview.chromium.org/141523010/diff/120001/ppapi/thunk/interfaces_...
ppapi/thunk/interfaces_ppb_public_stable.h:15: // Use the 'pepper_hash_for_uma'
tool in ppapi/tools to determine the hash for
Can we make a presubmit check that each addition to this file (and probably
other interfaces_.* files) has to have a corresponding change to histograms.xml?

Bonus:
The presubmit check could run pepper_hash_for_uma for the developer and display
the hash, or even make changes to histograms.xml automatically.

(No need to be in this CL.)

https://codereview.chromium.org/141523010/diff/120001/ppapi/tools/pepper_hash...
File ppapi/tools/pepper_hash_for_uma.cc (right):

https://codereview.chromium.org/141523010/diff/120001/ppapi/tools/pepper_hash...
ppapi/tools/pepper_hash_for_uma.cc:1: #include <stdio.h>
Do we need to have the copyright header?

[teravest, 2014-02-04 15:26:36]

On Mon, Feb 3, 2014 at 4:28 PM,  <yzshen@chromium.org> wrote:
>
>
https://codereview.chromium.org/141523010/diff/120001/ppapi/thunk/interfaces_...
> File ppapi/thunk/interfaces_ppb_public_stable.h (right):
>
>
https://codereview.chromium.org/141523010/diff/120001/ppapi/thunk/interfaces_...
> ppapi/thunk/interfaces_ppb_public_stable.h:15: // Use the
> 'pepper_hash_for_uma' tool in ppapi/tools to determine the hash for
> Can we make a presubmit check that each addition to this file (and
> probably other interfaces_.* files) has to have a corresponding change
> to histograms.xml?

Done.

>
> Bonus:
> The presubmit check could run pepper_hash_for_uma for the developer and
> display the hash, or even make changes to histograms.xml automatically.
>
> (No need to be in this CL.)

It would be nice if this was all automatic, but I don't know about
kicking off a build of that binary and running it as part of a
presubmit rule.

>
>
https://codereview.chromium.org/141523010/diff/120001/ppapi/tools/pepper_hash...
> File ppapi/tools/pepper_hash_for_uma.cc (right):
>
>
https://codereview.chromium.org/141523010/diff/120001/ppapi/tools/pepper_hash...
> ppapi/tools/pepper_hash_for_uma.cc:1: #include <stdio.h>
> Do we need to have the copyright header?

Done.

>
> https://codereview.chromium.org/141523010/

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[yzshen1, 2014-02-04 17:33:08]

>
https://codereview.chromium.org/141523010/diff/120001/ppapi/thunk/interfaces_...
> > File ppapi/thunk/interfaces_ppb_public_stable.h (right):
> >
> >
>
https://codereview.chromium.org/141523010/diff/120001/ppapi/thunk/interfaces_...
> > ppapi/thunk/interfaces_ppb_public_stable.h:15: // Use the
> > 'pepper_hash_for_uma' tool in ppapi/tools to determine the hash for
> > Can we make a presubmit check that each addition to this file (and
> > probably other interfaces_.* files) has to have a corresponding change
> > to histograms.xml?
> 
> Done.
> 
> >
> > Bonus:
> > The presubmit check could run pepper_hash_for_uma for the developer and
> > display the hash, or even make changes to histograms.xml automatically.
> >
> > (No need to be in this CL.)
> 
> It would be nice if this was all automatic, but I don't know about
> kicking off a build of that binary and running it as part of a
> presubmit rule.
> 
Yeah. I don't know either. Maybe writing the tool in script? (But I understand
that it may become inconsistent with the C++ code as the code evolves.)

LGTM

[Alexei Svitkine (slow), 2014-02-04 17:43:42]

Thanks, I think this will result in much more meaningful values on the
dashboard. A couple more comments below.

https://codereview.chromium.org/141523010/diff/280001/tools/metrics/histogram...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/141523010/diff/280001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:29034: +<enum name="PepperInterface"
type="int">
You can add a comment below this explaining how these are generated. (See other
examples - for e.g. EnterprisePolicies or FeatureObserver enums).

https://codereview.chromium.org/141523010/diff/280001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:29035: +  <int value="-2147196937"
label="PPB_FlashFullscreen;0.1"/>
Hmm, I don't think the UMA pipeline supports negative values as enum buckets.

Can you change the hash function to return the absolute value of the result (and
then update these appropriately)?

[dmichael (off chromium), 2014-02-04 17:50:32]

https://codereview.chromium.org/141523010/diff/280001/tools/metrics/histogram...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/141523010/diff/280001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:29035: +  <int value="-2147196937"
label="PPB_FlashFullscreen;0.1"/>
On 2014/02/04 17:43:42, Alexei Svitkine wrote:
> Hmm, I don't think the UMA pipeline supports negative values as enum buckets.
> 
> Can you change the hash function to return the absolute value of the result
(and
> then update these appropriately)?
Driveby...  The absolute value? It's a hash... it should just be a bunch of
bits. Doing absolute value sounds wrong. If negative values are not supported,
then the hash should be done to 31 bits or maybe 24 bits instead (which is a bit
unusual, but...  doable).

Why can't UMA support negative values? For hashes, it seems like it should just
treat this value as a sequence of 32 bits.

[Alexei Svitkine (slow), 2014-02-04 17:58:39]

On 2014/02/04 17:50:32, dmichael wrote:
>
https://codereview.chromium.org/141523010/diff/280001/tools/metrics/histogram...
> File tools/metrics/histograms/histograms.xml (right):
> 
>
https://codereview.chromium.org/141523010/diff/280001/tools/metrics/histogram...
> tools/metrics/histograms/histograms.xml:29035: +  <int value="-2147196937"
> label="PPB_FlashFullscreen;0.1"/>
> On 2014/02/04 17:43:42, Alexei Svitkine wrote:
> > Hmm, I don't think the UMA pipeline supports negative values as enum
buckets.
> > 
> > Can you change the hash function to return the absolute value of the result
> (and
> > then update these appropriately)?
> Driveby...  The absolute value? It's a hash... it should just be a bunch of
> bits. Doing absolute value sounds wrong. If negative values are not supported,
> then the hash should be done to 31 bits or maybe 24 bits instead (which is a
bit
> unusual, but...  doable).
> 
> Why can't UMA support negative values? For hashes, it seems like it should
just
> treat this value as a sequence of 32 bits.

There's no reason why it _couldn't_ support this, but it doesn't right now.

If someone was inclined, I can point them at the parts that would need to change
to support this (in the server-side processing pipeline), but it's not
completely trivial (which is why I suggest ensuring that the values are positive
as an easier fix).

[teravest, 2014-02-04 18:26:42]

On Tue, Feb 4, 2014 at 10:43 AM,  <asvitkine@chromium.org> wrote:
> Thanks, I think this will result in much more meaningful values on the
> dashboard. A couple more comments below.
>
>
>
https://codereview.chromium.org/141523010/diff/280001/tools/metrics/histogram...
> File tools/metrics/histograms/histograms.xml (right):
>
>
https://codereview.chromium.org/141523010/diff/280001/tools/metrics/histogram...
> tools/metrics/histograms/histograms.xml:29034: +<enum
> name="PepperInterface" type="int">
> You can add a comment below this explaining how these are generated.
> (See other examples - for e.g. EnterprisePolicies or FeatureObserver
> enums).

Done.

>
>
https://codereview.chromium.org/141523010/diff/280001/tools/metrics/histogram...
> tools/metrics/histograms/histograms.xml:29035: +  <int
> value="-2147196937" label="PPB_FlashFullscreen;0.1"/>
> Hmm, I don't think the UMA pipeline supports negative values as enum
> buckets.
>
> Can you change the hash function to return the absolute value of the
> result (and then update these appropriately)?

Done.

>
> https://codereview.chromium.org/141523010/

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Alexei Svitkine (slow), 2014-02-04 18:30:42]

https://codereview.chromium.org/141523010/diff/230013/ppapi/proxy/interface_l...
File ppapi/proxy/interface_list.cc (right):

https://codereview.chromium.org/141523010/diff/230013/ppapi/proxy/interface_l...
ppapi/proxy/interface_list.cc:334: int hash = static_cast<int>(data &
0x7fffffff);
Is base::Hash() guaranteed to never change implementation?

Can you add a test somewhere that would break when it does? (e.g. that checks
that base::Hash() produces one of the expected values for a given input - i.e.
use one or a few of the entries in histograms.xml as test cases?

This way, we can avoid any nasty surprises.

https://codereview.chromium.org/141523010/diff/230013/ppapi/tools/pepper_hash...
File ppapi/tools/pepper_hash_for_uma.cc (right):

https://codereview.chromium.org/141523010/diff/230013/ppapi/tools/pepper_hash...
ppapi/tools/pepper_hash_for_uma.cc:4: 
Can you maybe add a few lines of comment here about what this file is for and
how it's intended to be used?

[teravest, 2014-02-04 18:50:07]

On Tue, Feb 4, 2014 at 11:30 AM,  <asvitkine@chromium.org> wrote:
>
>
https://codereview.chromium.org/141523010/diff/230013/ppapi/proxy/interface_l...
> File ppapi/proxy/interface_list.cc (right):
>
>
https://codereview.chromium.org/141523010/diff/230013/ppapi/proxy/interface_l...
> ppapi/proxy/interface_list.cc:334: int hash = static_cast<int>(data &
> 0x7fffffff);
> Is base::Hash() guaranteed to never change implementation?
>
> Can you add a test somewhere that would break when it does? (e.g. that
> checks that base::Hash() produces one of the expected values for a given
> input - i.e. use one or a few of the entries in histograms.xml as test
> cases?
>
> This way, we can avoid any nasty surprises.

Done.

>
>
https://codereview.chromium.org/141523010/diff/230013/ppapi/tools/pepper_hash...
> File ppapi/tools/pepper_hash_for_uma.cc (right):
>
>
https://codereview.chromium.org/141523010/diff/230013/ppapi/tools/pepper_hash...
> ppapi/tools/pepper_hash_for_uma.cc:4:
> Can you maybe add a few lines of comment here about what this file is
> for and how it's intended to be used?

Done.

>
> https://codereview.chromium.org/141523010/

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Alexei Svitkine (slow), 2014-02-04 18:53:30]

LGTM % one last comment

Thanks!

https://codereview.chromium.org/141523010/diff/470001/ppapi/proxy/interface_l...
File ppapi/proxy/interface_list_unittest.cc (right):

https://codereview.chromium.org/141523010/diff/470001/ppapi/proxy/interface_l...
ppapi/proxy/interface_list_unittest.cc:71: int hash = static_cast<int>(data &
0x7fffffff);
Can you make a function in InterfaceList to compute the hash (including the
masking) and call it from this test, rather than duplicating the logic here?
That way, the two won't be able to diverge.

[teravest, 2014-02-04 19:01:38]

On Tue, Feb 4, 2014 at 11:53 AM,  <asvitkine@chromium.org> wrote:
> LGTM % one last comment
>
> Thanks!
>
>
>
https://codereview.chromium.org/141523010/diff/470001/ppapi/proxy/interface_l...
> File ppapi/proxy/interface_list_unittest.cc (right):
>
>
https://codereview.chromium.org/141523010/diff/470001/ppapi/proxy/interface_l...
> ppapi/proxy/interface_list_unittest.cc:71: int hash =
>
> static_cast<int>(data & 0x7fffffff);
> Can you make a function in InterfaceList to compute the hash (including
> the masking) and call it from this test, rather than duplicating the
> logic here? That way, the two won't be able to diverge.

Done.

>
> https://codereview.chromium.org/141523010/

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[teravest, 2014-02-04 19:17:09]

The CQ bit was checked by teravest@chromium.org

[commit-bot: I haz the power, 2014-02-04 19:23:43]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/teravest@chromium.org/141523010/520001

[commit-bot: I haz the power, 2014-02-04 20:23:58]

Retried try job too often on linux_rel for step(s) base_unittests,
browser_tests, interactive_ui_tests, net_unittests, unit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_rel&...

[commit-bot: I haz the power, 2014-02-04 20:26:27]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/teravest@chromium.org/141523010/520001

[commit-bot: I haz the power, 2014-02-05 00:50:43]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/teravest@chromium.org/141523010/520001

[teravest, 2014-02-05 15:34:27]

Committed patchset #12 manually as r249007 (presubmit successful).