Switch the default `git try` / `gcl try` bots to _rel.

Switch the default `git try` / `gcl try` bots to _rel.

That matches the CQ bots, and they're significantly faster.

The global trybots are added to all subdirectory PRESUBMITs automatically, so remove win, linux, mac from subdirectory PRESUBMITs (instead of changing them too).

BUG=99521
TEST=`git try` creates faster tryjobs.
TBR=willchan (net), akalin (sync)

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

[M-A Ruel, 2011-10-06 00:10:00]

Please don't. It keeps a higher priority of the CQ vs the try bots.

[Nico, 2011-10-06 00:12:48]

If all regular trybots get almost twice as fast, that's certainly a change for
the better, right?

I'd say that job priority shouldn't be handled by master name – the scheduler
could give jobs from cq@ a higher priority or something.

[M-A Ruel, 2011-10-06 00:17:41]

On 2011/10/06 00:12:48, Nico wrote:
> If all regular trybots get almost twice as fast, that's certainly a change for
> the better, right?
> 
> I'd say that job priority shouldn't be handled by master name – the
scheduler
> could give jobs from cq@ a higher priority or something.

Sure, but it doesn't at the moment and it's not yet on my priority list.

[Nico, 2011-10-06 00:34:16]

> Sure, but it doesn't at the moment and it's not yet on my priority list.

I can do that if it turns out to be necessary.

[Nico, 2011-10-06 01:00:23]

(right now both mac_rel and mac have pending jobs, which is what I was hoping to
prevent in the future with this change.)

[Nico, 2011-10-06 19:13:32]

ping

[M-A Ruel, 2011-10-06 19:30:50]

On 2011/10/06 19:13:32, Nico wrote:
> ping

Still, I need to shuffle the builders first.

[Nico, 2011-10-06 19:34:12]

> Still, I need to shuffle the builders first.

Why?

[Nico, 2011-10-06 20:39:00]

(we chatted. prioritization changed in recent buildbots, so this'll wait until

a) buildbot is updated
b) cq jobs have higher priority, blocked on a
)

[cmp, 2011-10-16 00:19:29]

+cc some people

Nicolas, you might be interested in this change especially.

[nsylvain, 2011-10-16 19:29:54]

On 2011/10/16 00:19:29, cmp wrote:
> +cc some people
> 
> Nicolas, you might be interested in this change especially.

Right. I'm interested. 

I'm actually against this change, but will not fight against it.  I'm just not
agreeing with the whole current trybot/cq situation.... Battles I've lost
already.

Just for the record, this is what I'm thinking:

I believe that the current 3 goals of the CQ are conflicting. 1. Running fast. 
2. Running all the tests. 3. Be used by everyone.   Achieving all those goals at
the same time, is, in my opinion, a losing battle. There is no way we can get
everyone to use the CQ if it takes more than half an hour to cycle. There is
also no way we can it make it run that fast if we run all the tests that we care
about.   I personally would do something like that:

Mandatory debug try bots that run all the tests we care about. (browser tests,
ui tests, etc).  It will be a little slow, but if people send the try job at the
same time they send the change for review, most of the time they actually won't
be waiting for the try job result as much as they are waiting for the LGTM to
come.  Once the try jobs are green, the commit queue just need to validate that
nothing regressed badly since the last try job by:
1. building release (which had not been built with the try bots)
2. running small but representative sets of tests : 1/20 shard of browser_tests,
ui_tests, base_unittests, net_unittests.

This should take < 30 minutes.

If the commit queue fails to catch a regression, at least the regression will be
manageable on the chrome tree, and will not require the tree to be closed for
hours. 

On the other hand, we're currently at a place where almost 70% of the commits
don't go through the commit queue, most likely because the CQ is too slow, and
people want to be around when the CQ commits their change.  That means that 70%
of the change have chances of screwing up the tree really badly.  This is bad,
and I don't see that improving if we continue to make the commit queue slow, by
running all the tests.

TL;DR; having try bots match CQ bots should be a non-goal.

[Nico, 2011-12-06 01:12:55]

It looks like all blockers for this are resolved by now (buildbots are upgraded;
szager gave cq priority). Is this good to go?

nsylvain: I don't have an opinion on what you're saying about the ideal state,
but this CL should dramatically improve the situation we have today.

[M-A Ruel, 2011-12-06 01:45:15]

No, I haven't finished upgrading the TS.

Le 5 décembre 2011 20:12, <thakis@chromium.org> a écrit :

> It looks like all blockers for this are resolved by now (buildbots are
> upgraded;
> szager gave cq priority). Is this good to go?
>
> nsylvain: I don't have an opinion on what you're saying about the ideal
> state,
> but this CL should dramatically improve the situation we have today.
>
>
http://codereview.chromium.**org/8162009/<http://codereview.chromium.org/8162...
>

[Nico, 2011-12-09 02:16:26]

I just landed a patch for cq prioritization, so after the next try master
restart this should be ready to go. Can I get a LGTM? (I won't submit before the
master restart happened.)

[M-A Ruel, 2011-12-09 18:47:25]

lgtm

[commit-bot: I haz the power, 2011-12-12 01:38:46]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/thakis@chromium.org/8162009/21001

[commit-bot: I haz the power, 2011-12-12 01:38:50]

Presubmit check for 8162009-21001 failed and returned exit status 1.

Running presubmit commit checks ...

** Presubmit ERRORS **
Missing LGTM from an OWNER for:
chrome/browser/sync/PRESUBMIT.py,net/PRESUBMIT.py

[Nico, 2011-12-12 01:40:45]

willchan, akalin: OWNERS tbr fyi

[commit-bot: I haz the power, 2011-12-12 01:40:57]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/thakis@chromium.org/8162009/21001

[commit-bot: I haz the power, 2011-12-12 03:05:08]

Change committed as 113979