Introduce a field trial for Instant.

Introduce a field trial for Instant.

Add a field trial for Instant, opting in 10% of undecided users into the
experiment. "Undecided" means that users who have played with the Instant
checkbox (in Preferences -> Basics) will be excluded from the field trial. When
Instant is turned on in this manner, it's restricted to search (i.e., other
non-search URLs are not previewed).

If the user is selected into the experiment, the checkbox state in preferences
will accurately reflect that Instant is on, even if the user didn't enable it
explicitly.

Although the experiment enables the "Restrict Instant to Search" functionality,
it's not reflected in about:flags. I consider this deficiency to be minor,
since (i) most users won't check about:flags anyway, and (ii) about:flags is
already inconsistent in other ways (for example, it also doesn't show if you
added --restrict-instant-to-search manually).

Similarly for --preload-instant-search, which preloads the default search
engine's homepage when the omnibox gets keyboard focus.

We respect group policy. If prefs::kInstantEnabled is a managed pref, the field
trial will not affect the user.

We store the actual random number generated for the user in a pref so that the
same user gets the same experience across browser restarts (i.e., one-time
randomization). This also allows us to change (through a Chrome update) the
percentages allocated to different groups and thus allocate users to groups
differently. If we only stored the final determination of the user's group in
the pref, changing the group percentages would have no effect.

The code doesn't use base::FieldTrial, because this experiment needs one-time
randomization, and base::FieldTrial only supports it if the user has opted-in
to UMA (see http://codereview.chromium.org/7360001/ for some context).

There is no explicit expiry date for this experiment. The experiment can be
disabled by updating the field trial percentages in instant_field_trial.cc and
shipping an update to Chrome (not much different from how base::FieldTrial also
requires new builds to expire experiments).

BUG=none
TEST=Delete profile and restart Chrome enough times to see that Instant is ON
by default about 10% of the time; fiddling with the preferences checkbox gives
expected results.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=94073

[sreeram, 2011-07-12 00:07:52]

Please review. I still need to fix several things, but I'd like your early look
and comments.

[sky, 2011-07-12 00:37:49]

http://codereview.chromium.org/7337007/diff/1/chrome/browser/autocomplete/aut...
File chrome/browser/autocomplete/autocomplete.h (right):

http://codereview.chromium.org/7337007/diff/1/chrome/browser/autocomplete/aut...
chrome/browser/autocomplete/autocomplete.h:603: explicit
AutocompleteController(const ACProviders& providers,
no explicit

http://codereview.chromium.org/7337007/diff/1/chrome/browser/instant/instant_...
File chrome/browser/instant/instant_field_trial.h (right):

http://codereview.chromium.org/7337007/diff/1/chrome/browser/instant/instant_...
chrome/browser/instant/instant_field_trial.h:19: // Returns true if the user is
part of the field trial experiment group.
Why do we need both IsExperiment and IsControl. Isn't it the case that if you
are either in the experiment or not in the experiment group?

I haven't looked at experiment code before, so I could totally be wrong. Either
way, could you clarify what it means to be in the experiment group and control
group.

[sky, 2011-07-12 00:39:05]

Also, 50% seems very large. I thought Brian wanted something like .1%? You
should run the number by him to make sure he is comfortable with it.

  -Scott

[sreeram, 2011-07-12 03:36:17]

http://codereview.chromium.org/7337007/diff/1/chrome/browser/autocomplete/aut...
File chrome/browser/autocomplete/autocomplete.h (right):

http://codereview.chromium.org/7337007/diff/1/chrome/browser/autocomplete/aut...
chrome/browser/autocomplete/autocomplete.h:603: explicit
AutocompleteController(const ACProviders& providers,
On 2011/07/12 00:37:50, sky wrote:
> no explicit

Good catch! Will do in the next patch.

http://codereview.chromium.org/7337007/diff/1/chrome/browser/instant/instant_...
File chrome/browser/instant/instant_field_trial.h (right):

http://codereview.chromium.org/7337007/diff/1/chrome/browser/instant/instant_...
chrome/browser/instant/instant_field_trial.h:19: // Returns true if the user is
part of the field trial experiment group.
On 2011/07/12 00:37:50, sky wrote:
> Why do we need both IsExperiment and IsControl. Isn't it the case that if you
> are either in the experiment or not in the experiment group?
> 
> I haven't looked at experiment code before, so I could totally be wrong.
Either
> way, could you clarify what it means to be in the experiment group and control
> group.

We need to be able to distinguish among these states:
1. Field trial is active, the user is in the experiment group (i.e., instant
enabled).
2. Field trial is active, the user is in the control group (i.e., instant
disabled).
3. Field trial is inactive (because the user has explicitly enabled/disabled the
preference, or because of group policy override, or because of incognito mode,
etc).

We want to log metrics for groups 1 and 2, but not for 3 (i.e., we want to avoid
those self-selected users). That's why we need both IsExperiment() (group 1) and
IsControl() (group 2).

[sreeram, 2011-07-12 03:37:50]

On Mon, Jul 11, 2011 at 17:39,  <sky@chromium.org> wrote:
> Also, 50% seems very large. I thought Brian wanted something like .1%? You
> should run the number by him to make sure he is comfortable with it.

Sure. We can treat the current numbers as placeholders for now. Closer
to submission, I'll figure out with Brian/Jeff what the right numbers
should be.

[sky, 2011-07-12 03:42:56]

I vote for an enum then.

Also, I think you should have a class with static functions rather
than namepace. Look for 'Namespace usage clarifications & rules.'

  -Scott

On Mon, Jul 11, 2011 at 8:36 PM,  <sreeram@chromium.org> wrote:
>
>
http://codereview.chromium.org/7337007/diff/1/chrome/browser/autocomplete/aut...
> File chrome/browser/autocomplete/autocomplete.h (right):
>
>
http://codereview.chromium.org/7337007/diff/1/chrome/browser/autocomplete/aut...
> chrome/browser/autocomplete/autocomplete.h:603: explicit
> AutocompleteController(const ACProviders& providers,
> On 2011/07/12 00:37:50, sky wrote:
>>
>> no explicit
>
> Good catch! Will do in the next patch.
>
>
http://codereview.chromium.org/7337007/diff/1/chrome/browser/instant/instant_...
> File chrome/browser/instant/instant_field_trial.h (right):
>
>
http://codereview.chromium.org/7337007/diff/1/chrome/browser/instant/instant_...
> chrome/browser/instant/instant_field_trial.h:19: // Returns true if the
> user is part of the field trial experiment group.
> On 2011/07/12 00:37:50, sky wrote:
>>
>> Why do we need both IsExperiment and IsControl. Isn't it the case that
>
> if you
>>
>> are either in the experiment or not in the experiment group?
>
>> I haven't looked at experiment code before, so I could totally be
>
> wrong. Either
>>
>> way, could you clarify what it means to be in the experiment group and
>
> control
>>
>> group.
>
> We need to be able to distinguish among these states:
> 1. Field trial is active, the user is in the experiment group (i.e.,
> instant enabled).
> 2. Field trial is active, the user is in the control group (i.e.,
> instant disabled).
> 3. Field trial is inactive (because the user has explicitly
> enabled/disabled the preference, or because of group policy override, or
> because of incognito mode, etc).
>
> We want to log metrics for groups 1 and 2, but not for 3 (i.e., we want
> to avoid those self-selected users). That's why we need both
> IsExperiment() (group 1) and IsControl() (group 2).
>
> http://codereview.chromium.org/7337007/
>

[sreeram, 2011-07-12 19:49:52]

On 2011/07/12 03:42:56, sky wrote:
> I vote for an enum then.

Done.

> Also, I think you should have a class with static functions rather
> than namepace. Look for 'Namespace usage clarifications & rules.'

Done.

[sreeram, 2011-07-21 16:34:19]

Please review. I'd like to try and get this in for M14 (by the Friday cutoff).

I've updated the CL description, so please read through it too.

Some more notes:

1. This CL incorporates the changes in the latest patch in
http://codereview.chromium.org/7396025/.

2. Instead of doing the webui to browser communication about
"isInstantFieldTrialExperimentGroup", it might be slightly less code to just
have the field trial set the prefs::kInstantEnabled pref. However, I didn't want
to do that because in the future, if we get rid of this field trial entirely (as
we intend to do, in a couple of months), I want the user's pref to be untouched.
If we set the pref, then we have to add _more_ code to unset it when the
experiment expires.

[sky, 2011-07-21 16:59:10]

The instant changes LGTM

[Evan Stade, 2011-07-21 22:42:11]

this seems to involve changes from http://codereview.chromium.org/7396025/ , is
there anything new you'd like me to review?

[Evan Stade, 2011-07-21 22:43:39]

also, I gather by your m14 push you want this to go into stable. Out of
curiosity, why do you want to do a field trial in stable instead of just canary
or dev?

[jar (doing other things), 2011-07-22 01:42:17]

http://codereview.chromium.org/7337007/diff/11001/chrome/browser/autocomplete...
File chrome/browser/autocomplete/autocomplete.cc (right):

http://codereview.chromium.org/7337007/diff/11001/chrome/browser/autocomplete...
chrome/browser/autocomplete/autocomplete.cc:888:
base::IntToString(text.length());
I'm not fully clear on the value of distinguishing based on text.length.  How is
that data helpful?

http://codereview.chromium.org/7337007/diff/11001/chrome/browser/autocomplete...
chrome/browser/autocomplete/autocomplete.cc:890: name, 1, 1000, 50,
base::Histogram::kUmaTargetedHistogramFlag);
You probably want a much larger dynamic range than 1000ms.  I'd suggest
something more like at least 30 seconds, maybe 10 minutes.  You won't lose much
resolution at the low end... but you'll get to see the tail of the distribution.

http://codereview.chromium.org/7337007/diff/11001/chrome/browser/instant/inst...
File chrome/browser/instant/instant_field_trial.cc (right):

http://codereview.chromium.org/7337007/diff/11001/chrome/browser/instant/inst...
chrome/browser/instant/instant_field_trial.cc:23: const double random =
prefs->GetDouble(prefs::kInstantFieldTrialRandomDraw);
IMO, you should use persistent prefs, and (as you noted), you'll only get to run
the tests on folks that have opt'ed into UMA.  Writing a random number into the
prefs is indeed marking the build with a unique ID, and as noted, that is
undesirable from a privacy perspective for some users.

http://codereview.chromium.org/7337007/diff/11001/chrome/common/pref_names.cc
File chrome/common/pref_names.cc (right):

http://codereview.chromium.org/7337007/diff/11001/chrome/common/pref_names.cc...
chrome/common/pref_names.cc:274: const char kInstantFieldTrialRandomDraw[] =
"instant.field_trial_random_draw";
Although I understand why you're doing this... I think it is a bad idea, as it
unwittingly tags each user uniquely (I think), unless you make the resolution
rather low.  Perhaps an integer in the range of 1-100 would be sufficient for
your needs, and not provide such tagging.  WDYT?

[sreeram, 2011-07-22 14:12:29]

On Thu, Jul 21, 2011 at 15:42,  <estade@chromium.org> wrote:
> this seems to involve changes from http://codereview.chromium.org/7396025/ ,
> is there anything new you'd like me to review?

Yeah, there are some small changes in webui. Sorry, they are not
easily visible because of the included patch. If you would LGTM that
:) I'd update this patch so that it reflects the merge accurately.

[sreeram, 2011-07-22 14:19:47]

On Thu, Jul 21, 2011 at 15:43,  <estade@chromium.org> wrote:
> also, I gather by your m14 push you want this to go into stable. Out of
> curiosity, why do you want to do a field trial in stable instead of just
> canary or dev?

We'd like to experiment (on a small fraction) of beta and stable users
because there are differences in their behaviour (with respect to
search metrics). For example, the average number of searches per user
per day is quite different between dev and stable users.

[sreeram, 2011-07-22 14:31:16]

http://codereview.chromium.org/7337007/diff/11001/chrome/browser/autocomplete...
File chrome/browser/autocomplete/autocomplete.cc (right):

http://codereview.chromium.org/7337007/diff/11001/chrome/browser/autocomplete...
chrome/browser/autocomplete/autocomplete.cc:888:
base::IntToString(text.length());
On 2011/07/22 01:42:17, jar wrote:
> I'm not fully clear on the value of distinguishing based on text.length.  How
is
> that data helpful?

I am not sure, but that's something that exists currently; I'm just adding the
field trial identifier to it.

http://codereview.chromium.org/7337007/diff/11001/chrome/browser/autocomplete...
chrome/browser/autocomplete/autocomplete.cc:890: name, 1, 1000, 50,
base::Histogram::kUmaTargetedHistogramFlag);
On 2011/07/22 01:42:17, jar wrote:
> You probably want a much larger dynamic range than 1000ms.  I'd suggest
> something more like at least 30 seconds, maybe 10 minutes.  You won't lose
much
> resolution at the low end... but you'll get to see the tail of the
distribution.

I think 1s is enough. This is a measure of the responsiveness of the omnibox, so
anything larger than a few tens of milliseconds would already be considered very
bad, so the 1s bucket already captures the tail of the distribution.

http://codereview.chromium.org/7337007/diff/11001/chrome/browser/instant/inst...
File chrome/browser/instant/instant_field_trial.cc (right):

http://codereview.chromium.org/7337007/diff/11001/chrome/browser/instant/inst...
chrome/browser/instant/instant_field_trial.cc:23: const double random =
prefs->GetDouble(prefs::kInstantFieldTrialRandomDraw);
On 2011/07/22 01:42:17, jar wrote:
> IMO, you should use persistent prefs, and (as you noted), you'll only get to
run
> the tests on folks that have opt'ed into UMA.  Writing a random number into
the
> prefs is indeed marking the build with a unique ID, and as noted, that is
> undesirable from a privacy perspective for some users.

Addressed by quantizing the random number.

http://codereview.chromium.org/7337007/diff/11001/chrome/common/pref_names.cc
File chrome/common/pref_names.cc (right):

http://codereview.chromium.org/7337007/diff/11001/chrome/common/pref_names.cc...
chrome/common/pref_names.cc:274: const char kInstantFieldTrialRandomDraw[] =
"instant.field_trial_random_draw";
On 2011/07/22 01:42:17, jar wrote:
> Although I understand why you're doing this... I think it is a bad idea, as it
> unwittingly tags each user uniquely (I think), unless you make the resolution
> rather low.  Perhaps an integer in the range of 1-100 would be sufficient for
> your needs, and not provide such tagging.  WDYT?

I think that's a fine idea! I'll change this to be a random integer in the range
[0, 10k). That will give us enough resolution to do groups of size 0.01%,
without uniquely marking the user.

[sreeram, 2011-07-25 14:59:17]

@sky: No substantial changes from before.

@estade: Updated to reflect the latest patch in
http://codereview.chromium.org/7396025/. There's still no easy way to see the
difference between that patch and this one, sorry. I had to add a prefs observer
(it wasn't enough to just hide/show the new checkbox in the onchange handler),
because the field trial may get disabled from underneath the prefs, for example,
if the pref suddenly becomes managed. The observer doesn't manipulate the pref
or checkbox though (other than showing/hiding it), so I think it's still in the
spirit of what we agreed on.

[Evan Stade, 2011-07-25 23:09:14]

On 2011/07/25 14:59:17, sreeram wrote:
> @sky: No substantial changes from before.
> 
> @estade: Updated to reflect the latest patch in
> http://codereview.chromium.org/7396025/. There's still no easy way to see the
> difference between that patch and this one, sorry.

yes, there is.

git cl upload [branchname to diff against]

> I had to add a prefs observer
> (it wasn't enough to just hide/show the new checkbox in the onchange handler),
> because the field trial may get disabled from underneath the prefs, for
example,
> if the pref suddenly becomes managed. The observer doesn't manipulate the pref
> or checkbox though (other than showing/hiding it), so I think it's still in
the
> spirit of what we agreed on.

[sreeram, 2011-07-26 00:07:27]

On 2011/07/25 23:09:14, Evan Stade wrote:
> git cl upload [branchname to diff against]

Done.

[Evan Stade, 2011-07-26 00:10:20]

http://codereview.chromium.org/7337007/diff/11007/chrome/browser/resources/op...
File chrome/browser/resources/options/browser_options.html (right):

http://codereview.chromium.org/7337007/diff/11007/chrome/browser/resources/op...
chrome/browser/resources/options/browser_options.html:97: <input
id="instantFieldTrialCheckbox" type="checkbox">
by default should be hidden.

http://codereview.chromium.org/7337007/diff/11007/chrome/browser/resources/op...
File chrome/browser/resources/options/browser_options.js (right):

http://codereview.chromium.org/7337007/diff/11007/chrome/browser/resources/op...
chrome/browser/resources/options/browser_options.js:193:
experiment_checkbox.checked = true;
this should always start as true. Thus it can be part of the html, no?

http://codereview.chromium.org/7337007/diff/11007/chrome/browser/resources/op...
chrome/browser/resources/options/browser_options.js:195:
preference_checkbox.style.display = "none";
foo.hidden = true/false

[sreeram, 2011-07-26 02:45:53]

http://codereview.chromium.org/7337007/diff/11007/chrome/browser/resources/op...
File chrome/browser/resources/options/browser_options.html (right):

http://codereview.chromium.org/7337007/diff/11007/chrome/browser/resources/op...
chrome/browser/resources/options/browser_options.html:97: <input
id="instantFieldTrialCheckbox" type="checkbox">
On 2011/07/26 00:10:21, Evan Stade wrote:
> by default should be hidden.

Done.

http://codereview.chromium.org/7337007/diff/11007/chrome/browser/resources/op...
File chrome/browser/resources/options/browser_options.js (right):

http://codereview.chromium.org/7337007/diff/11007/chrome/browser/resources/op...
chrome/browser/resources/options/browser_options.js:193:
experiment_checkbox.checked = true;
On 2011/07/26 00:10:21, Evan Stade wrote:
> this should always start as true. Thus it can be part of the html, no?

Done.

http://codereview.chromium.org/7337007/diff/11007/chrome/browser/resources/op...
chrome/browser/resources/options/browser_options.js:195:
preference_checkbox.style.display = "none";
On 2011/07/26 00:10:21, Evan Stade wrote:
> foo.hidden = true/false

Done.

[Sheridan Rawlins, 2011-07-26 07:07:15]

http://codereview.chromium.org/7337007/diff/20023/chrome/browser/instant/inst...
File chrome/browser/instant/instant_field_trial.h (right):

http://codereview.chromium.org/7337007/diff/20023/chrome/browser/instant/inst...
chrome/browser/instant/instant_field_trial.h:39: static bool
IsExperimentGroup(Profile* profile) {
Move this to .cc too

http://codereview.chromium.org/7337007/diff/20023/chrome/browser/resources/op...
File chrome/browser/resources/options/browser_options.js (right):

http://codereview.chromium.org/7337007/diff/20023/chrome/browser/resources/op...
chrome/browser/resources/options/browser_options.js:86:
$('instantFieldTrialCheckbox').onchange = function(event) {
Follow style of others in this file: use addEventListener('change',...) like
homepageField below.

http://codereview.chromium.org/7337007/diff/20023/chrome/browser/ui/webui/opt...
File chrome/browser/ui/webui/options/browser_options_handler.cc (right):

http://codereview.chromium.org/7337007/diff/20023/chrome/browser/ui/webui/opt...
chrome/browser/ui/webui/options/browser_options_handler.cc:134:
"getInstantFieldTrialStatus",
When you add messages here, you should update the mock
chrome/test/data/webui/options.js

[Sheridan Rawlins, 2011-07-26 07:16:59]

http://codereview.chromium.org/7337007/diff/20023/chrome/browser/autocomplete...
File chrome/browser/autocomplete/autocomplete.h (right):

http://codereview.chromium.org/7337007/diff/20023/chrome/browser/autocomplete...
chrome/browser/autocomplete/autocomplete.h:602: AutocompleteController(const
ACProviders& providers, Profile* profile)
Can you move this to .cc file too (so constructors are next to each other)? 
It'd be easier to see that both initialize profile_.

[sreeram, 2011-07-26 07:36:10]

http://codereview.chromium.org/7337007/diff/20023/chrome/browser/autocomplete...
File chrome/browser/autocomplete/autocomplete.h (right):

http://codereview.chromium.org/7337007/diff/20023/chrome/browser/autocomplete...
chrome/browser/autocomplete/autocomplete.h:602: AutocompleteController(const
ACProviders& providers, Profile* profile)
On 2011/07/26 07:16:59, Sheridan Rawlins wrote:
> Can you move this to .cc file too (so constructors are next to each other)? 
> It'd be easier to see that both initialize profile_.

Done.

http://codereview.chromium.org/7337007/diff/20023/chrome/browser/instant/inst...
File chrome/browser/instant/instant_field_trial.h (right):

http://codereview.chromium.org/7337007/diff/20023/chrome/browser/instant/inst...
chrome/browser/instant/instant_field_trial.h:39: static bool
IsExperimentGroup(Profile* profile) {
On 2011/07/26 07:07:15, Sheridan Rawlins wrote:
> Move this to .cc too

Done.

http://codereview.chromium.org/7337007/diff/20023/chrome/browser/resources/op...
File chrome/browser/resources/options/browser_options.js (right):

http://codereview.chromium.org/7337007/diff/20023/chrome/browser/resources/op...
chrome/browser/resources/options/browser_options.js:86:
$('instantFieldTrialCheckbox').onchange = function(event) {
On 2011/07/26 07:07:15, Sheridan Rawlins wrote:
> Follow style of others in this file: use addEventListener('change',...) like
> homepageField below.

Done.

http://codereview.chromium.org/7337007/diff/20023/chrome/browser/ui/webui/opt...
File chrome/browser/ui/webui/options/browser_options_handler.cc (right):

http://codereview.chromium.org/7337007/diff/20023/chrome/browser/ui/webui/opt...
chrome/browser/ui/webui/options/browser_options_handler.cc:134:
"getInstantFieldTrialStatus",
On 2011/07/26 07:07:15, Sheridan Rawlins wrote:
> When you add messages here, you should update the mock
> chrome/test/data/webui/options.js

As discussed on IRC, these tests seem to be passing (for example, see the linux
trybot results) without adding the message, so I'll leave this alone for now.

[Sheridan Rawlins, 2011-07-26 08:03:58]

LGTM for the review of the state after addressing others' concerns and double
checking memory usage for CallJavascript - should check for LG from OWNERS if
needed.

One nit - could you add a TODO(scr) line for the addition of the method by the
same name as the message you added (comment in
chrome/test/data/webui/options.js)?

[sreeram, 2011-07-26 08:23:35]

http://codereview.chromium.org/7337007/diff/20023/chrome/browser/autocomplete...
File chrome/browser/autocomplete/autocomplete.h (right):

http://codereview.chromium.org/7337007/diff/20023/chrome/browser/autocomplete...
chrome/browser/autocomplete/autocomplete.h:602: AutocompleteController(const
ACProviders& providers, Profile* profile)
On 2011/07/26 07:36:10, sreeram wrote:
> On 2011/07/26 07:16:59, Sheridan Rawlins wrote:
> > Can you move this to .cc file too (so constructors are next to each other)? 
> > It'd be easier to see that both initialize profile_.
> 
> Done.

I had to put this back. I think the conditional compilation (based on "#ifdef
UNIT_TEST") breaks if we move this to the .cc file, because if the .cc is
compiled without the macro being defined, and that library gets used for a unit
test target, then we get an "unresolved symbol" error.

[commit-bot: I haz the power, 2011-07-26 10:10:50]

Change committed as 94073

[willchan no longer on Chromium, 2011-07-26 11:09:21]

On 2011/07/26 10:10:50, I haz the power (commit-bot) wrote:
> Change committed as 94073

linux/mac/win trybots failed horribly on this changelist and it got sent to the
commit-bot anyway...why? The tree is flaming red now.

[sreeram, 2011-07-26 13:38:29]

On Tue, Jul 26, 2011 at 04:09,  <willchan@chromium.org> wrote:
> On 2011/07/26 10:10:50, I haz the power (commit-bot) wrote:
>>
>> Change committed as 94073
>
> linux/mac/win trybots failed horribly on this changelist and it got sent to
> the
> commit-bot anyway...why? The tree is flaming red now.
>
> http://codereview.chromium.org/7337007/

Sorry about that. Thanks for reverting it. I was under the impression
that the commit bot would reject the CL if things didn't work. I'd
been seeing a lot of flaky tests from the try bots, and so didn't
realize that I should have been more careful.

[willchan no longer on Chromium, 2011-07-26 13:43:10]

Np, it's fixed now. The commit-bot doesn't run browser_tests because
of flake. If you suspect a test is flaky, try running a tryjob again
and seeing if it goes away. Also try building browser_tests yourself
and running it to see if it fails on you.

Cheers.

On Tue, Jul 26, 2011 at 4:37 PM, Sreeram Ramachandran
<sreeram@chromium.org> wrote:
> On Tue, Jul 26, 2011 at 04:09,  <willchan@chromium.org> wrote:
>> On 2011/07/26 10:10:50, I haz the power (commit-bot) wrote:
>>>
>>> Change committed as 94073
>>
>> linux/mac/win trybots failed horribly on this changelist and it got sent to
>> the
>> commit-bot anyway...why? The tree is flaming red now.
>>
>> http://codereview.chromium.org/7337007/
>
> Sorry about that. Thanks for reverting it. I was under the impression
> that the commit bot would reject the CL if things didn't work. I'd
> been seeing a lot of flaky tests from the try bots, and so didn't
> realize that I should have been more careful.
>