Split the field trial setup code into desktop and mobile files.

Split the field trial setup code into desktop and mobile files.

BUG=233551
TEST=No visible impact.

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

[rohitrao (ping after 24h), 2013-04-19 13:46:24]

This still needs to be cleaned up a bit, but I wanted to make sure you were ok
with the high-level structure.

[SteveT, 2013-04-19 14:33:49]

Hey! Thanks a ton for doing this refactoring :)

A few comments for you to look at while cleaning up.

I definitely agree with this structure. Will approve once it's cleaned up and I
take a second look - let me know.

R+asvitkine who also owns this code and might have an opinion.

https://codereview.chromium.org/14247021/diff/1/chrome/browser/chrome_browser...
File chrome/browser/chrome_browser_field_trials_desktop.h (right):

https://codereview.chromium.org/14247021/diff/1/chrome/browser/chrome_browser...
chrome/browser/chrome_browser_field_trials_desktop.h:18: // SetupFieldTrials if
it is for all platforms.
Is it worth mentioning that SetupFieldTrials is actually in
chrome_browser_field_trials.cc?

https://codereview.chromium.org/14247021/diff/1/chrome/browser/chrome_browser...
chrome/browser/chrome_browser_field_trials_desktop.h:24: }  // end namespace
chrome
I don't think we usually put "end" in these namespace closing comments..?

https://codereview.chromium.org/14247021/diff/5001/chrome/browser/chrome_brow...
File chrome/browser/chrome_browser_field_trials_desktop.cc (right):

https://codereview.chromium.org/14247021/diff/5001/chrome/browser/chrome_brow...
chrome/browser/chrome_browser_field_trials_desktop.cc:184: 
nit: I think there should be just one line break here.

https://codereview.chromium.org/14247021/diff/5001/chrome/browser/chrome_brow...
File chrome/browser/chrome_browser_field_trials_desktop.h (right):

https://codereview.chromium.org/14247021/diff/5001/chrome/browser/chrome_brow...
chrome/browser/chrome_browser_field_trials_desktop.h:18: // SetupFieldTrials if
it is for all platforms.
Is it worth mentioning that SetupFieldTrials is from
chrome_browser_field_trials.cc?

https://codereview.chromium.org/14247021/diff/5001/chrome/browser/chrome_brow...
chrome/browser/chrome_browser_field_trials_desktop.h:24: }  // end namespace
chrome
Some comment here about "end". I don't think we usually include it?

https://codereview.chromium.org/14247021/diff/5001/chrome/browser/chrome_brow...
File chrome/browser/chrome_browser_field_trials_mobile.h (right):

https://codereview.chromium.org/14247021/diff/5001/chrome/browser/chrome_brow...
chrome/browser/chrome_browser_field_trials_mobile.h:17: // Add invocation of
your field trial initialization code in this method.
Did you want to include a comment here about how all-platform trials should go
in SetupFieldTrials in chrome_browser_field_trials.cc, to be consistent with the
Desktop comment?

[rohitrao (ping after 24h), 2013-04-19 14:42:58]

Addressed comments and cleaned up all of the stale includes.  Trybots seem
happy.

I think this is ready for a real look now.

https://codereview.chromium.org/14247021/diff/5001/chrome/browser/chrome_brow...
File chrome/browser/chrome_browser_field_trials_desktop.cc (right):

https://codereview.chromium.org/14247021/diff/5001/chrome/browser/chrome_brow...
chrome/browser/chrome_browser_field_trials_desktop.cc:184: 
On 2013/04/19 14:33:49, SteveT wrote:
> nit: I think there should be just one line break here.

Done.

https://codereview.chromium.org/14247021/diff/5001/chrome/browser/chrome_brow...
File chrome/browser/chrome_browser_field_trials_desktop.h (right):

https://codereview.chromium.org/14247021/diff/5001/chrome/browser/chrome_brow...
chrome/browser/chrome_browser_field_trials_desktop.h:18: // SetupFieldTrials if
it is for all platforms.
On 2013/04/19 14:33:49, SteveT wrote:
> Is it worth mentioning that SetupFieldTrials is from
> chrome_browser_field_trials.cc?

Done.

https://codereview.chromium.org/14247021/diff/5001/chrome/browser/chrome_brow...
chrome/browser/chrome_browser_field_trials_desktop.h:24: }  // end namespace
chrome
On 2013/04/19 14:33:49, SteveT wrote:
> Some comment here about "end". I don't think we usually include it?

Done.

https://codereview.chromium.org/14247021/diff/5001/chrome/browser/chrome_brow...
File chrome/browser/chrome_browser_field_trials_mobile.h (right):

https://codereview.chromium.org/14247021/diff/5001/chrome/browser/chrome_brow...
chrome/browser/chrome_browser_field_trials_mobile.h:17: // Add invocation of
your field trial initialization code in this method.
On 2013/04/19 14:33:49, SteveT wrote:
> Did you want to include a comment here about how all-platform trials should go
> in SetupFieldTrials in chrome_browser_field_trials.cc, to be consistent with
the
> Desktop comment?

Copied the same comment from the desktop file.

[Alexei Svitkine (slow), 2013-04-19 15:32:44]

Is there a reason the current ifdef'd approach doesn't work for iOS, or is this
merely to make the coder cleaner (i.e. have less ifdefs)?

https://codereview.chromium.org/14247021/diff/11002/chrome/browser/chrome_bro...
File chrome/browser/chrome_browser_field_trials_desktop.cc (right):

https://codereview.chromium.org/14247021/diff/11002/chrome/browser/chrome_bro...
chrome/browser/chrome_browser_field_trials_desktop.cc:175:
base::FieldTrialList::FindValue("UMA-Dynamic-Uniformity-Trial");
We want this on mobile too.

The two UMA-* trials plus the Test0* trial are some trials we use for testing
the system. These calls are needed, so that their state is reported through
metrics (else Chrome considers the trials to never be used and not report their
state).

Also see:

https://codereview.chromium.org/13954011/

Where I'm re-enabling this block in the pre-refactored code. (Which will cause
some conflicts with this CL.)

[rohitrao (ping after 24h), 2013-04-19 15:39:50]

> Is there a reason the current ifdef'd approach doesn't work for iOS, or is
this
> merely to make the coder cleaner (i.e. have less ifdefs)?

Mostly to make the code look cleaner.  Most of the desktop trials code fails to
link on iOS, so it's not enough to simply comment out the single call to
SetupDesktopFieldTrials().  I'd have to ifdef out 90% of the file.

> chrome/browser/chrome_browser_field_trials_desktop.cc:175:
> base::FieldTrialList::FindValue("UMA-Dynamic-Uniformity-Trial");
> We want this on mobile too.

My refactoring should be a pure no-op.  If we need to move things around, I
think that should be done separately.


> Where I'm re-enabling this block in the pre-refactored code. (Which will cause
> some conflicts with this CL.)

Can I go first?  I think it will be easier to resolve conflicts that way =)

[Alexei Svitkine (slow), 2013-04-19 15:47:22]

On 2013/04/19 15:39:50, rohitrao wrote:
> Can I go first?  I think it will be easier to resolve conflicts that way =)

Myself already has all the LGTMs and the Flywheel team is pretty anxious to get
the VS on Android, so I'd like to not delay it further...

[rohitrao (ping after 24h), 2013-04-19 15:48:18]

On 2013/04/19 15:47:22, Alexei Svitkine wrote:
> On 2013/04/19 15:39:50, rohitrao wrote:
> > Can I go first?  I think it will be easier to resolve conflicts that way =)
> 
> Myself already has all the LGTMs and the Flywheel team is pretty anxious to
get
> the VS on Android, so I'd like to not delay it further...

Sigh.  Ok, I will try to resolve the conflicts on my end without rewriting my CL
from scratch =)

[Alexei Svitkine (slow), 2013-04-19 15:48:21]

On 2013/04/19 15:47:22, Alexei Svitkine wrote:
> On 2013/04/19 15:39:50, rohitrao wrote:
> > Can I go first?  I think it will be easier to resolve conflicts that way =)
> 
> Myself already has all the LGTMs and the Flywheel team is pretty anxious to
get
> the VS on Android, so I'd like to not delay it further...

That was not supposed to be an actually L G T M.

[rohitrao (ping after 24h), 2013-04-22 11:12:15]

Ok, rebased on top of Alexei's changes.  This is ready for another look.

[Alexei Svitkine (slow), 2013-04-22 14:55:21]

lgtm

[Alexei Svitkine (slow), 2013-04-22 14:55:21]

lgtm

[rohitrao (ping after 24h), 2013-04-22 15:03:00]

+thakis for OWNERS approval of chrome_browser.gypi.

[rohitrao (ping after 24h), 2013-04-22 15:03:50]

On 2013/04/22 15:03:00, rohitrao wrote:
> +thakis for OWNERS approval of chrome_browser.gypi.

Actually, Nico, your approval is probably going to cover the changes to
chrome/browser/OWNERS also.

[SteveT, 2013-04-22 15:06:16]

lgtm

[Nico, 2013-04-22 17:20:57]

lgtm

I wonder if _mobile / _desktop should be part of build/filename_rules.gypi .

[commit-bot: I haz the power, 2013-04-22 18:40:55]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/14247021/14001

[commit-bot: I haz the power, 2013-04-23 00:23:52]

Change committed as 195654

[rohitrao (ping after 24h), 2013-04-23 06:51:52]

On 2013/04/22 17:20:57, Nico wrote:
> lgtm
> 
> I wonder if _mobile / _desktop should be part of build/filename_rules.gypi .

Yeah, I think this is worth considering, since we're starting to get a critical
mass of files that follow this convention.  I remember resistance to
OS_DESKTOP/OS_MOBILE macros, but that was a while ago, and macros are different
from filenames.

I'll ask Stuart to follow up on this when he gets back next week.

Thanks for the reviews everyone!

[Nico, 2014-04-22 22:08:32]

https://chromiumcodereview.appspot.com/14247021/diff/14001/chrome/browser/chr...
File chrome/browser/chrome_browser_field_trials_mobile.cc (right):

https://chromiumcodereview.appspot.com/14247021/diff/14001/chrome/browser/chr...
chrome/browser/chrome_browser_field_trials_mobile.cc:19: // Always enabled in
DEV and BETA versions.
I saw this today. What's the motivation for this? It seems that beta and dev
should test what we ship to stable, at least by some percentage. As is, beta and
dev only test the compression proxy, and then we launch to stable and the
non-compression-codepath has had almost no testing in the field.

[rohitrao (ping after 24h), 2014-04-22 22:59:07]

+Mark FYI

If I remember correctly, this trial controls the visibility of the bandwidth
settings menu, but not whether or not the proxy is enabled.  So 100% of dev/beta
users have the setting, but they haven't necessarily turned it on.

[marq (ping after 24h), 2014-04-24 00:45:31]

https://chromiumcodereview.appspot.com/14247021/diff/14001/chrome/browser/chr...
File chrome/browser/chrome_browser_field_trials_mobile.cc (right):

https://chromiumcodereview.appspot.com/14247021/diff/14001/chrome/browser/chr...
chrome/browser/chrome_browser_field_trials_mobile.cc:19: // Always enabled in
DEV and BETA versions.
On 2014/04/22 22:08:33, Nico wrote:
> I saw this today. What's the motivation for this? It seems that beta and dev
> should test what we ship to stable, at least by some percentage. As is, beta
and
> dev only test the compression proxy, and then we launch to stable and the
> non-compression-codepath has had almost no testing in the field.

Nico,

This trial just gated exposure of the settings control for users to enable the
proxy. There wasn't a "non-compression" codepath that didn't get exercised (even
with the proxy on, https and incognito tabs weren't proxied).

In any case, this has been a 100% stable feature for several milestones, and
this code will probabaly be removed in the near future.

[Nico, 2014-04-24 00:47:50]

On Wed, Apr 23, 2014 at 5:45 PM, <[email protected]> wrote:

>
> https://chromiumcodereview.appspot.com/14247021/diff/
> 14001/chrome/browser/chrome_browser_field_trials_mobile.cc
> File chrome/browser/chrome_browser_field_trials_mobile.cc (right):
>
> https://chromiumcodereview.appspot.com/14247021/diff/
> 14001/chrome/browser/chrome_browser_field_trials_mobile.cc#newcode19
> chrome/browser/chrome_browser_field_trials_mobile.cc:19: // Always
> enabled in DEV and BETA versions.
> On 2014/04/22 22:08:33, Nico wrote:
>
>> I saw this today. What's the motivation for this? It seems that beta
>>
> and dev
>
>> should test what we ship to stable, at least by some percentage. As
>>
> is, beta and
>
>> dev only test the compression proxy, and then we launch to stable and
>>
> the
>
>> non-compression-codepath has had almost no testing in the field.
>>
>
> Nico,
>
> This trial just gated exposure of the settings control for users to
> enable the proxy. There wasn't a "non-compression" codepath that didn't
> get exercised (even with the proxy on, https and incognito tabs weren't
> proxied).
>
> In any case, this has been a 100% stable feature for several milestones,
> and this code will probabaly be removed in the near future.
>

Looking forward to that CL!

To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].