Hi sunnpyps@, we provide an endpoint on the dashboard: https://chromeperf.appspot.com/migrate_test_names so that you can do the migrates yourself. Since you're renaming a lot of pages, yeah it's probably best you put together a spreadsheet and enter them 1 by 1.

Actually, if you provide the spreadsheet of names I'll run through this since it can be a bit finicky occasionally.

Sheet with new names:

https://docs.google.com/spreadsheets/d/1flmA2VB0Mk2VdIHLMh_sN9WYF3EGfCQZyWNdI865LJI/edit#gid=0

There are two sub-sheets for key_mobile_sites_smooth and top_25_smooth.

Should I go ahead and land the CLs for renaming the pages in code? Not sure what comes first, renaming on the dashboard or renaming in code.

Sunny, people typically renaming in code first, then renaming on the dashboard

FWIW I couldn't access the migrate_test_names end point with either my chromium account or corp account.

Yeah lemme know when this is landed and I can follow up with renaming for you.

Both CLs have landed.

So quick question, there are a lot of cros bots that also have this test, should I be restricting this to chromiumperf or everything?

Similarly, there are benchmarks outside of the ones you mention that seem to have similar page names, ie. smoothness.gpu_rasterization.top_25_smooth, should I be doing to blanket across everything or restrict it only to the benchmarks mentioned in the first post?

cywang, nednguyen: does CrOS use the same version of smoothness as the rest of chrome, or does it do something like https://cs.chromium.org/chromium/src/tools/perf/contrib/cros_benchmarks/ ?

There are going to be a lot of changes to this benchmark, should we branch to contrib to avoid breaking CrOS, or will it pick up the changes too?

These smoothness benchmarks are going away soon. The reason for renaming the pages is to make them sane for the upcoming rendering benchmark that combines smoothness and thread_times. Is it necessary to rename pages on the dashboard at all?

The only benefit of renaming is if you want a continuous timeeseries for the exact same page/metric; and that only works if you are going to keep the pages and metrics the same. We don't need this from the perf dashboard/perf sherifing perspective, but you should check with vmiura and sadrul if it's needed on their end.

+ sadrul, vmiura

With the benchmark migration, all metrics in thread_times and smoothness will be part of the rendering benchmark. That benchmark will have two page sets - desktop and mobile.

Pages will be migrated like the following example:

smoothness.top_25_smooth/cnn becomes rendering.desktop/cnn (or scroll_cnn or to distinguish from pinch_zoom_cnn - undecided on this point)

However, since the mobile page set has both desktop and mobile pages for cnn:

smoothness.key_mobile_sites_smooth/cnn becomes rendering.mobile/cnn
smoothness.top_25_smooth/cnn becomes rendering.mobile/cnn_desktop
smoothness.gpu_rasterization.top_25_smooth/cnn becomes rendering.mobile/cnn_desktop_gpu_raster

Not sure if renaming the pages in smoothness benchmarks helps with this case at all.

Update on #9: it looks like ChromeOS already branched the smoothness benchmark so this work won't affect them. Let's restrict the migration to ChromiumPerf waterfall.

We want to migrate all affected smoothness benchmarks. I mentioned these in
c#0:

smoothness.key_mobile_sites_smooth
smoothness.sync_scroll.key_mobile_sites_smooth
thread_times.key_mobile_sites_smooth

smoothness.top_25_smooth
smoothness.gpu_rasterization.top_25_smooth

Are there others that I missed?

Alright sounds good, I'll ping this when the migration is done.

Small update, this is still in progress.

So I think this should be done, doesn't seem to be any more tasks in the queue.

I had made some reports with a few of the pages:

https://chromeperf.appspot.com/report?sid=f9f94e63ab5fef3fbe242bd1bd0a4b963c71cca7d7a771dd023122482fdd2ad4
https://chromeperf.appspot.com/report?sid=b52a587e8059d38a83654376919f04e9c7a297eed43aa079432cb2c6f0120b3c

Seems to have migrated everything (except there's an existing Pinterest that maybe needs to migrated, not really sure, maybe someone can look at it).

I'll leave this open in case anybody wants to take a look at that, otherwise this could be closed up.

It's not just Pinterest, but any page that used the URL instead of story name in the json. Telemetry uses URL as fallback when it can't find story by name in the json (see  issue 810616 ).

Sheet with stories that weren't renamed correctly because of this: https://docs.google.com/spreadsheets/d/1er6rN4-5LwwUJ3G9PrzYa-bUAKtLIs1uzF6S1GvmfxY/edit?usp=sharing

Ok migrations have started (luckily I still had my script around from the first one to do these kind of mass migrations. :)

https://chromeperf.appspot.com/report?sid=070d5b2354e18309dcc7ca7cea9e572fe5e859ff45b377346da217b887f31794
https://chromeperf.appspot.com/report?sid=6f04960290c4793640585ed287dfbd63cbc5c90c46af09a0bc24c97f1675b1b3

Made 2 sample reports (they just have a few of the pages, it's not exhaustive). This will probably take until tomorrow at the earliest.

@sunnyps

Looks like this finished and the test paths have been migrateed. I noticed LinkedIn was also in the key_mobile_sites_smooth pages but not listed in the spreadsheet, do you want that migrated?

Yes, please migrate LinkedIn to linkedin for key_mobile_sites_smooth.

Ok checked back and linkedin has been migrated.

Thanks!