Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
703453004:
Plugin Power Saver: Add some UMAs to test plugins in wild. (Closed)
DescriptionPlugin Power Saver: Add some UMAs to test plugins in wild.
Collect some UMAs for expected plugin behavior, even when flag
is off. We want to gather some data on how this feature impacts
users before turning it on.
Design doc: http://goo.gl/iDix3p
BUG=403800
Committed: https://crrev.com/b997edc53d9bc1104e0231cf905925b6587898c0
Cr-Commit-Position: refs/heads/master@{#303201}
Patch Set 1 #Patch Set 2 : #Patch Set 3 : #
Total comments: 2
Patch Set 4 : #Patch Set 5 : #Patch Set 6 : removed plugininstancecreated #
Total comments: 8
Patch Set 7 : rebase on top of crash fix. address thestigcomments. #Patch Set 8 : rebase onto master #Patch Set 9 : add back plugininstancecreated uma #
Total comments: 12
Patch Set 10 : #Patch Set 11 : #
Total comments: 2
Patch Set 12 : #
Total comments: 6
Patch Set 13 : try reupload #
Messages
Total messages: 39 (9 generated)
tommycli@chromium.org changed reviewers: + groby@chromium.org, thestig@chromium.org
thestig / groby: How does this set of UMAs?
We should discuss whether we want to count plugin instances or pages or both.
We need both, I think. Which means we somewhere need per-page counts for these, bucketized into histograms. https://codereview.chromium.org/703453004/diff/40001/content/renderer/pepper/... File content/renderer/pepper/pepper_plugin_instance_impl.cc (right): https://codereview.chromium.org/703453004/diff/40001/content/renderer/pepper/... content/renderer/pepper/pepper_plugin_instance_impl.cc:614: base::UserMetricsAction("Flash.PluginInstancePeripheral")); Can we roll Peripheral, EssentialCrossOrigin, EssentialSameOrigin into a histogram (Side benefit: PluginInstanceCreated is the sum of all these
thestig/groby: Made the heuristic initial decision a histogram. I left the Flash.PluginInstanceCreated action alone, as I believe Lei had some plans for it?
https://codereview.chromium.org/703453004/diff/40001/content/renderer/pepper/... File content/renderer/pepper/pepper_plugin_instance_impl.cc (right): https://codereview.chromium.org/703453004/diff/40001/content/renderer/pepper/... content/renderer/pepper/pepper_plugin_instance_impl.cc:614: base::UserMetricsAction("Flash.PluginInstancePeripheral")); On 2014/11/04 20:49:19, groby wrote: > Can we roll Peripheral, EssentialCrossOrigin, EssentialSameOrigin into a > histogram (Side benefit: PluginInstanceCreated is the sum of all these Done.
On 2014/11/04 21:48:12, tommycli wrote: > thestig/groby: Made the heuristic initial decision a histogram. > > I left the Flash.PluginInstanceCreated action alone, as I believe Lei had some > plans for it? I don't have any special plans.
On 2014/11/04 21:56:18, Lei Zhang wrote: > On 2014/11/04 21:48:12, tommycli wrote: > > thestig/groby: Made the heuristic initial decision a histogram. > > > > I left the Flash.PluginInstanceCreated action alone, as I believe Lei had some > > plans for it? > > I don't have any special plans. Okay. I removed Flash.PluginInstanceCreated as suggested by groby@ then.
This looks like a per-plugin-instance histogram. Are we going to do per-page in this CL or another CL? https://codereview.chromium.org/703453004/diff/100001/content/renderer/pepper... File content/renderer/pepper/pepper_plugin_instance_impl.cc (left): https://codereview.chromium.org/703453004/diff/100001/content/renderer/pepper... content/renderer/pepper/pepper_plugin_instance_impl.cc:619: RenderThread::Get()->RecordAction( The sum of the Plugin.PowerSaverPeripheralHeuristic histogram is equivalent, so I guess we don't need this. https://codereview.chromium.org/703453004/diff/100001/content/renderer/pepper... File content/renderer/pepper/pepper_plugin_instance_impl.cc (right): https://codereview.chromium.org/703453004/diff/100001/content/renderer/pepper... content/renderer/pepper/pepper_plugin_instance_impl.cc:593: power_saver_helper->ShouldThrottleContent(content_origin, bounds.width, curious, is this part of the change due to git cl format? https://codereview.chromium.org/703453004/diff/100001/content/renderer/pepper... content/renderer/pepper/pepper_plugin_instance_impl.cc:597: CommandLine::ForCurrentProcess()->HasSwitch( nit: base::CommandLine https://codereview.chromium.org/703453004/diff/100001/content/renderer/pepper... File content/renderer/pepper/plugin_power_saver_helper.cc (right): https://codereview.chromium.org/703453004/diff/100001/content/renderer/pepper... content/renderer/pepper/plugin_power_saver_helper.cc:26: PERIPHERAL_HEURISTIC_DECISION_ESSENTIAL_CROSS_ORIGIN_WHITELISTED = 2, value should be 3?
thestig: addressed your comments https://codereview.chromium.org/703453004/diff/100001/content/renderer/pepper... File content/renderer/pepper/pepper_plugin_instance_impl.cc (left): https://codereview.chromium.org/703453004/diff/100001/content/renderer/pepper... content/renderer/pepper/pepper_plugin_instance_impl.cc:619: RenderThread::Get()->RecordAction( On 2014/11/05 01:23:49, Lei Zhang wrote: > The sum of the Plugin.PowerSaverPeripheralHeuristic histogram is equivalent, so > I guess we don't need this. I think we should keep it if you can think of any reason to. I like an explicit count vs. the histogram thing, which could change in the future. Are histograms kept over all users? Or is it a sparse collection set? Would keeping the UMA give us a better count of the instances? https://codereview.chromium.org/703453004/diff/100001/content/renderer/pepper... File content/renderer/pepper/pepper_plugin_instance_impl.cc (right): https://codereview.chromium.org/703453004/diff/100001/content/renderer/pepper... content/renderer/pepper/pepper_plugin_instance_impl.cc:593: power_saver_helper->ShouldThrottleContent(content_origin, bounds.width, On 2014/11/05 01:23:49, Lei Zhang wrote: > curious, is this part of the change due to git cl format? Yes. It was a change by git cl format. https://codereview.chromium.org/703453004/diff/100001/content/renderer/pepper... content/renderer/pepper/pepper_plugin_instance_impl.cc:597: CommandLine::ForCurrentProcess()->HasSwitch( On 2014/11/05 01:23:49, Lei Zhang wrote: > nit: base::CommandLine Done. https://codereview.chromium.org/703453004/diff/100001/content/renderer/pepper... File content/renderer/pepper/plugin_power_saver_helper.cc (right): https://codereview.chromium.org/703453004/diff/100001/content/renderer/pepper... content/renderer/pepper/plugin_power_saver_helper.cc:26: PERIPHERAL_HEURISTIC_DECISION_ESSENTIAL_CROSS_ORIGIN_WHITELISTED = 2, On 2014/11/05 01:23:49, Lei Zhang wrote: > value should be 3? Done.
Patchset #9 (id:160001) has been deleted
Patchset #9 (id:180001) has been deleted
tommycli@chromium.org changed reviewers: + isherman@chromium.org, raymes@chromium.org
thestig: Added back the PluginInstanceCreated UMA. raymes/isherman: PTAL, thanks!
lgtm
https://codereview.chromium.org/703453004/diff/200001/tools/metrics/histogram... File tools/metrics/histograms/histograms.xml (right): https://codereview.chromium.org/703453004/diff/200001/tools/metrics/histogram... tools/metrics/histograms/histograms.xml:25080: + heuristic. Mention this is per instance.
https://codereview.chromium.org/703453004/diff/200001/content/renderer/pepper... File content/renderer/pepper/plugin_power_saver_helper.cc (right): https://codereview.chromium.org/703453004/diff/200001/content/renderer/pepper... content/renderer/pepper/plugin_power_saver_helper.cc:109: PERIPHERAL_HEURISTIC_DECISION_NUM_ITEMS); Optional nit: It's typically useful to define a wrapper function for each UMA_HISTOGRAM_ENUMERATION, so that you can call RecordPeripheralHeuristicMetric(PERIPHERAL_HEURISTIC_DECISION_PERIPHERAL). It leads to shorter, and thus often more bug-free, code. https://codereview.chromium.org/703453004/diff/200001/tools/metrics/actions/a... File tools/metrics/actions/actions.xml (right): https://codereview.chromium.org/703453004/diff/200001/tools/metrics/actions/a... tools/metrics/actions/actions.xml:2680: </action> Are you sure you want to log these as actions rather than as an enumerated histogram? What advantage do you see from logging these as actions? (It might be the right choice, but I'd like to understand the context so that I can provide better guidance.) https://codereview.chromium.org/703453004/diff/200001/tools/metrics/histogram... File tools/metrics/histograms/histograms.xml (right): https://codereview.chromium.org/703453004/diff/200001/tools/metrics/histogram... tools/metrics/histograms/histograms.xml:51252: + <int value="3" label="Essential Cross-Origin Whitelisted"/> These labels are a bit mysterious to me. Perhaps you could expand the histogram description to give a bit more of a hint of what the heuristic is doing?
isherman: Addressed your comments. Thanks. https://codereview.chromium.org/703453004/diff/200001/content/renderer/pepper... File content/renderer/pepper/plugin_power_saver_helper.cc (right): https://codereview.chromium.org/703453004/diff/200001/content/renderer/pepper... content/renderer/pepper/plugin_power_saver_helper.cc:109: PERIPHERAL_HEURISTIC_DECISION_NUM_ITEMS); On 2014/11/05 22:36:19, Ilya Sherman wrote: > Optional nit: It's typically useful to define a wrapper function for each > UMA_HISTOGRAM_ENUMERATION, so that you can call > RecordPeripheralHeuristicMetric(PERIPHERAL_HEURISTIC_DECISION_PERIPHERAL). It > leads to shorter, and thus often more bug-free, code. Done. Good suggestion. Can I modify the enum values to be shorter too? Like DECISION_PERIPHERAL, DECISION_ESSENTIAL_CROSS_ORIGIN_WHITELISTED ? https://codereview.chromium.org/703453004/diff/200001/tools/metrics/actions/a... File tools/metrics/actions/actions.xml (right): https://codereview.chromium.org/703453004/diff/200001/tools/metrics/actions/a... tools/metrics/actions/actions.xml:2680: </action> On 2014/11/05 22:36:19, Ilya Sherman wrote: > Are you sure you want to log these as actions rather than as an enumerated > histogram? What advantage do you see from logging these as actions? (It might > be the right choice, but I'd like to understand the context so that I can > provide better guidance.) I thought these might be 'actions' since not every plugin is unthrottled. We expect that many plugins that get throttled are never unthrottled. Do we log every single user action / histogram, or do we take a sparse sampling from our users? https://codereview.chromium.org/703453004/diff/200001/tools/metrics/histogram... File tools/metrics/histograms/histograms.xml (right): https://codereview.chromium.org/703453004/diff/200001/tools/metrics/histogram... tools/metrics/histograms/histograms.xml:25080: + heuristic. On 2014/11/05 22:32:56, Lei Zhang wrote: > Mention this is per instance. Done. https://codereview.chromium.org/703453004/diff/200001/tools/metrics/histogram... tools/metrics/histograms/histograms.xml:51252: + <int value="3" label="Essential Cross-Origin Whitelisted"/> On 2014/11/05 22:36:20, Ilya Sherman wrote: > These labels are a bit mysterious to me. Perhaps you could expand the histogram > description to give a bit more of a hint of what the heuristic is doing? Done.
https://codereview.chromium.org/703453004/diff/240001/content/renderer/pepper... File content/renderer/pepper/pepper_plugin_instance_impl.h (right): https://codereview.chromium.org/703453004/diff/240001/content/renderer/pepper... content/renderer/pepper/pepper_plugin_instance_impl.h:732: scoped_ptr<PepperPluginInstanceThrottler> throttler_; There's a growing number of power-saver related members and logic here. How do you feel about factoring this out into a helper class? This class is already too big and complex so any effort in keeping it smaller is much appreciated! I'm ok with this being done in a followup CL. A plausible interface for this class could be something like: class PepperPluginPowerSaver { public: PepperPluginPowerSaver(PepperPluginInstanceImpl* instance, ...); bool is_throttled(); const ppapi::ViewData& throttled_view_data(); // Consumes an input event if the plugin is throttled and returns true. // (this would contain all the logic in HandleInputEvent) bool ConsumeInputEvent(const blink::WebInputEvent& event); private: void SetPluginThrottled(bool throttled) { ... instance_->SendDidChangeView)(); } void DisablePowerSaverAndUnthrottle(); bool power_saver_enabled_; bool is_peripheral_content_; bool plugin_throttled_; // Consider just combining this class with the throttler. scoped_ptr<PepperPluginInstanceThrottler> throttler_; }
https://codereview.chromium.org/703453004/diff/200001/content/renderer/pepper... File content/renderer/pepper/plugin_power_saver_helper.cc (right): https://codereview.chromium.org/703453004/diff/200001/content/renderer/pepper... content/renderer/pepper/plugin_power_saver_helper.cc:109: PERIPHERAL_HEURISTIC_DECISION_NUM_ITEMS); On 2014/11/06 00:36:05, tommycli wrote: > On 2014/11/05 22:36:19, Ilya Sherman wrote: > > Optional nit: It's typically useful to define a wrapper function for each > > UMA_HISTOGRAM_ENUMERATION, so that you can call > > RecordPeripheralHeuristicMetric(PERIPHERAL_HEURISTIC_DECISION_PERIPHERAL). It > > leads to shorter, and thus often more bug-free, code. > > Done. > > Good suggestion. Can I modify the enum values to be shorter too? Like > DECISION_PERIPHERAL, DECISION_ESSENTIAL_CROSS_ORIGIN_WHITELISTED ? My understanding of the style guide is that you can use a class enum, and then have shorter constant names. Honestly, for an enum that's defined in the anonymous namespace, and hence not visible externally to this compilation unit, you can probably use short constant names anyway. But, that's more a matter for this file's OWNERS to weigh in on, if they care to. https://codereview.chromium.org/703453004/diff/200001/tools/metrics/actions/a... File tools/metrics/actions/actions.xml (right): https://codereview.chromium.org/703453004/diff/200001/tools/metrics/actions/a... tools/metrics/actions/actions.xml:2680: </action> On 2014/11/06 00:36:05, tommycli wrote: > On 2014/11/05 22:36:19, Ilya Sherman wrote: > > Are you sure you want to log these as actions rather than as an enumerated > > histogram? What advantage do you see from logging these as actions? (It > might > > be the right choice, but I'd like to understand the context so that I can > > provide better guidance.) > > I thought these might be 'actions' since not every plugin is unthrottled. We > expect that many plugins that get throttled are never unthrottled. > > Do we log every single user action / histogram, or do we take a sparse sampling > from our users? The idea of building a histogram would be to have a histogram that has one bucket that records e.g. the number of plugin instances that are created, and to have two other buckets for recording how many times such plugins were unthrottled, either by click or by whitelist. The nice thing about histograms is that they have context built in to them -- you don't have to guess at which other actions are meant to be used as baselines. We do log every single user action and every single histogram (well, for users who are opted in to sharing metrics, of course). The main advantages of user actions are that (a) they have timestamps associated with them, and (b) they allow easy comparisons to arbitrary other actions. As a result, actions are typically used to measure user interactions with Chrome, and especially to gauge feature usage at a high level. The main advantages of histograms are that (a) they are more efficient, (b) they have a built-in baseline, which often makes data analysis much easier, and (c) they are much better supported on the dashboard side. Hence, histograms are typically used when adding metrics that are designed to answer specific questions like "How often are plugins getting unthrottled?", where you expect that comparing events recorded in your histogram with events like "How many times did a user enable Autofill?" is not a useful comparison.
raymes, isherman: thanks, see below https://codereview.chromium.org/703453004/diff/200001/content/renderer/pepper... File content/renderer/pepper/plugin_power_saver_helper.cc (right): https://codereview.chromium.org/703453004/diff/200001/content/renderer/pepper... content/renderer/pepper/plugin_power_saver_helper.cc:109: PERIPHERAL_HEURISTIC_DECISION_NUM_ITEMS); On 2014/11/06 03:30:30, Ilya Sherman wrote: > On 2014/11/06 00:36:05, tommycli wrote: > > On 2014/11/05 22:36:19, Ilya Sherman wrote: > > > Optional nit: It's typically useful to define a wrapper function for each > > > UMA_HISTOGRAM_ENUMERATION, so that you can call > > > RecordPeripheralHeuristicMetric(PERIPHERAL_HEURISTIC_DECISION_PERIPHERAL). > It > > > leads to shorter, and thus often more bug-free, code. > > > > Done. > > > > Good suggestion. Can I modify the enum values to be shorter too? Like > > DECISION_PERIPHERAL, DECISION_ESSENTIAL_CROSS_ORIGIN_WHITELISTED ? > > My understanding of the style guide is that you can use a class enum, and then > have shorter constant names. Honestly, for an enum that's defined in the > anonymous namespace, and hence not visible externally to this compilation unit, > you can probably use short constant names anyway. But, that's more a matter for > this file's OWNERS to weigh in on, if they care to. Done. https://codereview.chromium.org/703453004/diff/200001/tools/metrics/actions/a... File tools/metrics/actions/actions.xml (right): https://codereview.chromium.org/703453004/diff/200001/tools/metrics/actions/a... tools/metrics/actions/actions.xml:2680: </action> On 2014/11/06 03:30:30, Ilya Sherman wrote: > On 2014/11/06 00:36:05, tommycli wrote: > > On 2014/11/05 22:36:19, Ilya Sherman wrote: > > > Are you sure you want to log these as actions rather than as an enumerated > > > histogram? What advantage do you see from logging these as actions? (It > > might > > > be the right choice, but I'd like to understand the context so that I can > > > provide better guidance.) > > > > I thought these might be 'actions' since not every plugin is unthrottled. We > > expect that many plugins that get throttled are never unthrottled. > > > > Do we log every single user action / histogram, or do we take a sparse > sampling > > from our users? > > The idea of building a histogram would be to have a histogram that has one > bucket that records e.g. the number of plugin instances that are created, and to > have two other buckets for recording how many times such plugins were > unthrottled, either by click or by whitelist. The nice thing about histograms > is that they have context built in to them -- you don't have to guess at which > other actions are meant to be used as baselines. > > We do log every single user action and every single histogram (well, for users > who are opted in to sharing metrics, of course). The main advantages of user > actions are that (a) they have timestamps associated with them, and (b) they > allow easy comparisons to arbitrary other actions. As a result, actions are > typically used to measure user interactions with Chrome, and especially to gauge > feature usage at a high level. > > The main advantages of histograms are that (a) they are more efficient, (b) they > have a built-in baseline, which often makes data analysis much easier, and (c) > they are much better supported on the dashboard side. Hence, histograms are > typically used when adding metrics that are designed to answer specific > questions like "How often are plugins getting unthrottled?", where you expect > that comparing events recorded in your histogram with events like "How many > times did a user enable Autofill?" is not a useful comparison. Okay that was very helpful. I made it a histogram. I added a third possibility of 'Never' to denote plugins that are throttled but never unthrottled. With the three options combined, we should be able to get a clear picture of what happens to ALL plugins after they get throttled. https://codereview.chromium.org/703453004/diff/240001/content/renderer/pepper... File content/renderer/pepper/pepper_plugin_instance_impl.h (right): https://codereview.chromium.org/703453004/diff/240001/content/renderer/pepper... content/renderer/pepper/pepper_plugin_instance_impl.h:732: scoped_ptr<PepperPluginInstanceThrottler> throttler_; On 2014/11/06 02:11:00, raymes wrote: > There's a growing number of power-saver related members and logic here. How do > you feel about factoring this out into a helper class? This class is already too > big and complex so any effort in keeping it smaller is much appreciated! > > I'm ok with this being done in a followup CL. > > A plausible interface for this class could be something like: > > class PepperPluginPowerSaver { > public: > PepperPluginPowerSaver(PepperPluginInstanceImpl* instance, ...); > > bool is_throttled(); > const ppapi::ViewData& throttled_view_data(); > > // Consumes an input event if the plugin is throttled and returns true. > // (this would contain all the logic in HandleInputEvent) > bool ConsumeInputEvent(const blink::WebInputEvent& event); > > private: > void SetPluginThrottled(bool throttled) { > ... > instance_->SendDidChangeView)(); > } > void DisablePowerSaverAndUnthrottle(); > > bool power_saver_enabled_; > bool is_peripheral_content_; > bool plugin_throttled_; > > // Consider just combining this class with the throttler. > scoped_ptr<PepperPluginInstanceThrottler> throttler_; > > } No problem. I realize I'm adding a bunch of junk. I'll clean it all up in a followup CL, promise.
https://codereview.chromium.org/703453004/diff/260001/content/renderer/pepper... File content/renderer/pepper/pepper_plugin_instance_impl.cc (right): https://codereview.chromium.org/703453004/diff/260001/content/renderer/pepper... content/renderer/pepper/pepper_plugin_instance_impl.cc:1167: if (plugin_throttled_) { I'm not sure if this is correct anymore. Before this CL, we used to be able to unthrottle the plugin even after power_saver_enabled_ == false. It seems like right now we can end up in a state where is_peripheral_content_ goes from true to false, then plugin_throttled_ gets set to true and then we can never set it back to false? Another advantage to shifting this logic out to another class is we can write a unittest to test this :)
https://codereview.chromium.org/703453004/diff/260001/content/renderer/pepper... File content/renderer/pepper/pepper_plugin_instance_impl.cc (right): https://codereview.chromium.org/703453004/diff/260001/content/renderer/pepper... content/renderer/pepper/pepper_plugin_instance_impl.cc:1167: if (plugin_throttled_) { On 2014/11/06 22:24:48, raymes wrote: > I'm not sure if this is correct anymore. Before this CL, we used to be able to > unthrottle the plugin even after power_saver_enabled_ == false. It seems like > right now we can end up in a state where is_peripheral_content_ goes from true > to false, then plugin_throttled_ gets set to true and then we can never set it > back to false? > > Another advantage to shifting this logic out to another class is we can write a > unittest to test this :) I think this is okay, as the body of SetPluginThrottled says: if (!power_saver_enabled_ && throttled) return; Since power_saver_enabled_ goes to false at the same time as is_peripheral_content_, it should never be allowed be throttled when is_peripheral_content_ is false. I could be wrong, but that's my reasoning. I agree that refactoring it out to a separate class will be good.
lgtm https://codereview.chromium.org/703453004/diff/260001/content/renderer/pepper... File content/renderer/pepper/pepper_plugin_instance_impl.cc (right): https://codereview.chromium.org/703453004/diff/260001/content/renderer/pepper... content/renderer/pepper/pepper_plugin_instance_impl.cc:1167: if (plugin_throttled_) { Ok yep I think I agree! Please still do add a test with the refactor that tests this. It's subtle and prone to break and it's easy to test.
Metrics LGTM, thanks. https://codereview.chromium.org/703453004/diff/260001/tools/metrics/actions/a... File tools/metrics/actions/actions.xml (right): https://codereview.chromium.org/703453004/diff/260001/tools/metrics/actions/a... tools/metrics/actions/actions.xml:2662: <description>Count of Flash plugin instances.</description> nit: Is this change still relevant to your CL? (I'm genuinely unsure -- mostly as long as Lei is happy with it, it's fine.)
isherman/raymes: Thanks! thestig: Feel free to object. https://codereview.chromium.org/703453004/diff/260001/tools/metrics/actions/a... File tools/metrics/actions/actions.xml (right): https://codereview.chromium.org/703453004/diff/260001/tools/metrics/actions/a... tools/metrics/actions/actions.xml:2662: <description>Count of Flash plugin instances.</description> On 2014/11/06 23:52:05, Ilya Sherman wrote: > nit: Is this change still relevant to your CL? (I'm genuinely unsure -- mostly > as long as Lei is happy with it, it's fine.) Yes. The old description was out of date.
The CQ bit was checked by tommycli@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/703453004/260001
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: chromium_presubmit on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
https://codereview.chromium.org/703453004/diff/260001/tools/metrics/actions/a... File tools/metrics/actions/actions.xml (right): https://codereview.chromium.org/703453004/diff/260001/tools/metrics/actions/a... tools/metrics/actions/actions.xml:2662: <description>Count of Flash plugin instances.</description> On 2014/11/06 23:52:05, Ilya Sherman wrote: > nit: Is this change still relevant to your CL? (I'm genuinely unsure -- mostly > as long as Lei is happy with it, it's fine.) Yes, this is fine.
The CQ bit was checked by tommycli@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/703453004/280001
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: chromium_presubmit on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
The CQ bit was checked by tommycli@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/703453004/280001
Message was sent while issue was closed.
Committed patchset #13 (id:280001)
Message was sent while issue was closed.
Patchset 13 (id:??) landed as https://crrev.com/b997edc53d9bc1104e0231cf905925b6587898c0 Cr-Commit-Position: refs/heads/master@{#303201} |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
