Remove PowerUsageMonitor.

Remove PowerUsageMonitor.

It is no longer reporting good data and other power benchmarks are being
developed.

Review-Url: https://codereview.chromium.org/2716593006
Cr-Commit-Position: refs/heads/master@{#456264}
Committed: https://chromium.googlesource.com/chromium/src/+/43624541fe9d3f03badfab95ab582d4530318154

[Lei Zhang, 2017-02-24 20:14:48]

The CQ bit was checked by thestig@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-24 20:15:29]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-24 21:58:53]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-24 21:58:54]

Dry run: This issue passed the CQ dry run.

[brucedawson, 2017-02-24 23:38:42]

brucedawson@chromium.org changed reviewers:
+ brucedawson@chromium.org

[brucedawson, 2017-02-24 23:38:43]

lgtm

[Lei Zhang, 2017-02-24 23:41:35]

thestig@chromium.org changed reviewers:
+ mpearson@chromium.org

[Lei Zhang, 2017-02-24 23:41:36]

+mpearson for histograms.

[Mark P, 2017-02-24 23:42:35]

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

https://codereview.chromium.org/2716593006/diff/1/tools/metrics/histograms/hi...
tools/metrics/histograms/histograms.xml:50064: +    Deprecated 02/2017 in favor
of better power benchmarks.
optional nit: mention the better benchmark (histograms) by name.
ditto below

[Mark P, 2017-02-27 23:48:35]

oops, meant to lgtm with my one nit (posted on an earlier message)

--mark

[Lei Zhang, 2017-02-28 00:40:50]

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

https://codereview.chromium.org/2716593006/diff/1/tools/metrics/histograms/hi...
tools/metrics/histograms/histograms.xml:50064: +    Deprecated 02/2017 in favor
of better power benchmarks.
On 2017/02/24 23:42:35, Mark P wrote:
> optional nit: mention the better benchmark (histograms) by name.
> ditto below

My understanding is there are forthcoming power benchmarks that do not depend on
UMA. There's too much variability in power figures from users' machines.

[Mark P, 2017-02-28 00:42:18]

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

https://codereview.chromium.org/2716593006/diff/1/tools/metrics/histograms/hi...
tools/metrics/histograms/histograms.xml:50064: +    Deprecated 02/2017 in favor
of better power benchmarks.
On 2017/02/28 00:40:50, Lei Zhang (super slow) wrote:
> On 2017/02/24 23:42:35, Mark P wrote:
> > optional nit: mention the better benchmark (histograms) by name.
> > ditto below
> 
> My understanding is there are forthcoming power benchmarks that do not depend
on
> UMA. There's too much variability in power figures from users' machines.

Then please say that these UMA metrics aren't retired because we have better UMA
metrics but that they're retired because you don't trust them due to too much
variability from users' machines.

[Lei Zhang, 2017-02-28 02:21:35]

Description was changed from

==========
Remove PowerUsageMonitor.

It is no longer reporting good data and other power benchmarks are being
developed.
==========

to

==========
Remove PowerUsageMonitor.

It is no longer reporting good data and other power benchmarks are being
developed.
==========

[Lei Zhang, 2017-02-28 02:27:36]

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

https://codereview.chromium.org/2716593006/diff/1/tools/metrics/histograms/hi...
tools/metrics/histograms/histograms.xml:50064: +    Deprecated 02/2017 in favor
of better power benchmarks.
On 2017/02/28 00:42:18, Mark P wrote:
> On 2017/02/28 00:40:50, Lei Zhang (super slow) wrote:
> > On 2017/02/24 23:42:35, Mark P wrote:
> > > optional nit: mention the better benchmark (histograms) by name.
> > > ditto below
> > 
> > My understanding is there are forthcoming power benchmarks that do not
depend
> on
> > UMA. There's too much variability in power figures from users' machines.
> 
> Then please say that these UMA metrics aren't retired because we have better
UMA
> metrics but that they're retired because you don't trust them due to too much
> variability from users' machines.

Done. +benhenry to sanity check what I wrote.

[Mark P, 2017-02-28 04:45:52]

still histograms.xml lgtm

[Lei Zhang, 2017-03-11 00:58:53]

The CQ bit was checked by thestig@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-11 00:59:16]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-11 02:16:15]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-11 02:16:16]

Dry run: This issue passed the CQ dry run.

[Lei Zhang, 2017-03-11 02:50:16]

The CQ bit was checked by thestig@chromium.org

[Lei Zhang, 2017-03-11 02:50:17]

The patchset sent to the CQ was uploaded after l-g-t-m from
brucedawson@chromium.org
Link to the patchset: https://codereview.chromium.org/2716593006/#ps20001
(title: "Adjust comment")

[commit-bot: I haz the power, 2017-03-11 02:50:27]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-11 02:56:02]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1489200616902340,
"parent_rev": "09d53300b8970af32280827cac93e10ede07a1f0", "commit_rev":
"43624541fe9d3f03badfab95ab582d4530318154"}

[commit-bot: I haz the power, 2017-03-11 02:56:41]

Description was changed from

==========
Remove PowerUsageMonitor.

It is no longer reporting good data and other power benchmarks are being
developed.
==========

to

==========
Remove PowerUsageMonitor.

It is no longer reporting good data and other power benchmarks are being
developed.

Review-Url: https://codereview.chromium.org/2716593006
Cr-Commit-Position: refs/heads/master@{#456264}
Committed:
https://chromium.googlesource.com/chromium/src/+/43624541fe9d3f03badfab95ab58...
==========

[commit-bot: I haz the power, 2017-03-11 02:56:42]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/43624541fe9d3f03badfab95ab58...

[shrike, 2017-03-12 20:17:16]

shrike@chromium.org changed reviewers:
+ shrike@chromium.org

[shrike, 2017-03-12 20:17:17]

Hello thestig@,

Why isn't there a bug that discusses the reason for removing this monitor? This
is a multi-platform monitor, so does the remark that it's no longer returning
good results apply to just Windows or to all platforms? I currently have an
experiment on the Mac that is using one of its metrics, and chirp is complaining
it can no longer find it. It seems like experimenters relying on this monitor
should have been at least notified beforehand of the removal?

[Lei Zhang, 2017-03-13 18:51:13]

On 2017/03/12 20:17:17, shrike wrote:
> Hello thestig@,
> 
> Why isn't there a bug that discusses the reason for removing this monitor?
This
> is a multi-platform monitor, so does the remark that it's no longer returning
> good results apply to just Windows or to all platforms? I currently have an
> experiment on the Mac that is using one of its metrics, and chirp is
complaining
> it can no longer find it. It seems like experimenters relying on this monitor
> should have been at least notified beforehand of the removal?

I started discussing it over email with speed folks because the directory had no
OWNERS. The feedback I got was the metric is broken / not useful and should be
deleted.

It wasn't obvious what experiements were affected by this, as the experiments
exist in a different repo.

Do you want me to revert? Do you want to take ownership of this code?

[blundell, 2017-03-20 08:26:29]

On 2017/03/13 18:51:13, Lei Zhang (super slow) wrote:
> On 2017/03/12 20:17:17, shrike wrote:
> > Hello thestig@,
> > 
> > Why isn't there a bug that discusses the reason for removing this monitor?
> This
> > is a multi-platform monitor, so does the remark that it's no longer
returning
> > good results apply to just Windows or to all platforms? I currently have an
> > experiment on the Mac that is using one of its metrics, and chirp is
> complaining
> > it can no longer find it. It seems like experimenters relying on this
monitor
> > should have been at least notified beforehand of the removal?
> 
> I started discussing it over email with speed folks because the directory had
no
> OWNERS. The feedback I got was the metric is broken / not useful and should be
> deleted.
> 
> It wasn't obvious what experiements were affected by this, as the experiments
> exist in a different repo.
> 
> Do you want me to revert? Do you want to take ownership of this code?

shrike@/thestig@: If you revert this CL, do you mind reopening crbug.com/686011
as well? Thanks!

Conversely, note that if you *don't* reland this code soon, //device/battery
will become completely hidden inside the Device Service, and whatever new
approach is taken will need to interact with the Device Sevice via
//services/device/public/interfaces/battery_monitor.mojom instead (which
shouldn't be hard, and I can help there).

[shrike, 2017-03-24 16:48:11]

On 2017/03/20 08:26:29, blundell wrote:
> shrike@/thestig@: If you revert this CL, do you mind reopening
crbug.com/686011
> as well? Thanks!
> 
> Conversely, note that if you *don't* reland this code soon, //device/battery
> will become completely hidden inside the Device Service, and whatever new
> approach is taken will need to interact with the Device Sevice via
> //services/device/public/interfaces/battery_monitor.mojom instead (which
> shouldn't be hard, and I can help there).

At the moment I'm not convinced of the usefulness of this metric.

[shrike, 2017-03-24 16:48:12]

On 2017/03/20 08:26:29, blundell wrote:
> shrike@/thestig@: If you revert this CL, do you mind reopening
crbug.com/686011
> as well? Thanks!
> 
> Conversely, note that if you *don't* reland this code soon, //device/battery
> will become completely hidden inside the Device Service, and whatever new
> approach is taken will need to interact with the Device Sevice via
> //services/device/public/interfaces/battery_monitor.mojom instead (which
> shouldn't be hard, and I can help there).

At the moment I'm not convinced of the usefulness of this metric.