Change chromium CQ global retry quota 2->1

Change chromium CQ global retry quota 2->1

This is an attempt to get 90% cycle time under 2 hours.

Currently cycle time is considered higher priority than false rejections,
although we try to keep both low.

BUG=none
R=sergiyb@chromium.org, tandrii@chromium.org

Committed: https://chromium.googlesource.com/chromium/src/+/bfd6ebdc7511f63ebae483cc82ce5ed989f470ca

[Paweł Hajdan Jr., 2015-11-24 14:02:24]

phajdan.jr@chromium.org changed reviewers:
+ akuegel@chromium.org, sergiyb@chromium.org, tandrii@chromium.org

[tandrii(chromium), 2015-11-24 14:02:46]

LGTM

[Sergiy Byelozyorov, 2015-11-24 14:10:31]

lgtm

[Adrian Kuegel, 2015-11-24 14:13:53]

I don't like this very much, but if you all feel this does what developers want,
then go for it.

[commit-bot: I haz the power, 2015-11-24 14:20:50]

Patchset 1 (id:??) landed as
https://crrev.com/bfd6ebdc7511f63ebae483cc82ce5ed989f470ca
Cr-Commit-Position: refs/heads/master@{#361336}

[Paweł Hajdan Jr., 2015-11-24 14:21:10]

Committed patchset #1 (id:1) manually as
bfd6ebdc7511f63ebae483cc82ce5ed989f470ca (presubmit successful).

[jam, 2015-12-17 21:19:42]

I just saw this. 

My main question is: hasn't this been 2 (or more) for a long time? If so, then
reducing this to 1 seems like it's making another experience worse (increasing
number of CQ jobs that don't make it through) instead of fixing the root cause
for this regression.


Do we have good stats about what exactly is contributing to the delay in 90th?
this change seems to presume flakiness; can you share data?

[jam, 2015-12-17 21:53:31]

On 2015/12/17 21:19:42, jam wrote:
> I just saw this. 
> 
> My main question is: hasn't this been 2 (or more) for a long time? If so, then
> reducing this to 1 seems like it's making another experience worse (increasing
> number of CQ jobs that don't make it through) instead of fixing the root cause
> for this regression.
> 
> 
> Do we have good stats about what exactly is contributing to the delay in 90th?
> this change seems to presume flakiness; can you share data?

also, from the weekly stats, this doesn't appear to have an effect on 90th
percentile time.

[Adrian Kuegel, 2015-12-18 09:15:30]

On 2015/12/17 21:53:31, jam wrote:
> On 2015/12/17 21:19:42, jam wrote:
> > I just saw this. 
> > 
> > My main question is: hasn't this been 2 (or more) for a long time? If so,
then
> > reducing this to 1 seems like it's making another experience worse
(increasing
> > number of CQ jobs that don't make it through) instead of fixing the root
cause
> > for this regression.
> > 
> > 
> > Do we have good stats about what exactly is contributing to the delay in
90th?
> > this change seems to presume flakiness; can you share data?
> 
> also, from the weekly stats, this doesn't appear to have an effect on 90th
> percentile time.

Yes, I already mentioned it in a CQ meeting that this change didn't seem to have
the intended effect. And it could possibly cause more false CQ rejections.
So from the data we see some part of the regression was probably caused by slow
android builder, by overloaded linux tryserver and capacity issues with iOS, but
it is difficult to gather exactly what contributed the most.

[chromium-reviews, 2015-12-18 09:26:29]

I think we should revert it then. Pawel, can you please do so if you agree.

On Fri, Dec 18, 2015 at 10:15 AM <akuegel@chromium.org> wrote:

> On 2015/12/17 21:53:31, jam wrote:
> > On 2015/12/17 21:19:42, jam wrote:
> > > I just saw this.
> > >
> > > My main question is: hasn't this been 2 (or more) for a long time? If
> > so,
> then
> > > reducing this to 1 seems like it's making another experience worse
> (increasing
> > > number of CQ jobs that don't make it through) instead of fixing the
> root
> cause
> > > for this regression.
> > >
> > >
> > > Do we have good stats about what exactly is contributing to the delay
> in
> 90th?
> > > this change seems to presume flakiness; can you share data?
>
> > also, from the weekly stats, this doesn't appear to have an effect on
> 90th
> > percentile time.
>
> Yes, I already mentioned it in a CQ meeting that this change didn't seem to
> have
> the intended effect. And it could possibly cause more false CQ rejections.
> So from the data we see some part of the regression was probably caused by
> slow
> android builder, by overloaded linux tryserver and capacity issues with
> iOS, but
> it is difficult to gather exactly what contributed the most.
>
> https://codereview.chromium.org/1474703002/
>
-- 
Sergiy Byelozyorov | Software Engineer | sergiyb@google.com

Google Germany GmbH
Dienerstraße 12
80331 München

AG Hamburg, HRB 86891 | Sitz der Gesellschaft: Hamburg | Geschäftsführer:
Matthew Scott Sucherman, Paul Terence Manicle

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[jam, 2016-01-27 18:19:21]

ping?

[Paweł Hajdan Jr., 2016-01-27 19:29:10]

On 2016/01/27 at 18:19:21, jam wrote:
> ping?

Sorry, I just happened to see comments on this closed CL but I usually don't.

I started
https://groups.google.com/a/chromium.org/d/msg/infra-dev/i3yr44DDVNo/M6Cut45t...
with some thoughts.

Feel free to change if you really want to. Watch out for regression of CQ cycle
times though.

[jam, 2016-02-24 17:17:15]

A revert of this CL (patchset #1 id:1) has been created in
https://codereview.chromium.org/1731353002/ by jam@chromium.org.

The reason for reverting is: Patch didn't affect 90% cycle time..