1161282 - Prioritize try jobs higher that are using try syntax to reduce load

Status: RESOLVED INCOMPLETE

(Release Engineering :: General, defect)

Description

[Chris AtLee [:catlee]]

We should reward people who push to try with a limited set of jobs (e.g. using the new --tag arguments from bug 978846) by prioritizing their jobs higher than other try jobs.

Comment 1

[Gregory Szorc [:gps]]

This is a great idea except for the times when it isn't. Any job where a full run is often needed would lose out by this change... unless we identify which jobs those are and except that from being down-weighted.

Comment 2

[Gregory Szorc [:gps]]

Err, I meant to ask which jobs typically need full runs?

I /think/ reftest would fall in this list.

xpcshell certainly doesn't. mochitest almost certainly doesn't.

Comment 3

[Chris AtLee [:catlee]]

Mostly I'm thinking that if you're restricting your try set in some way, either by platform, or by test suite, or by tag, then you should be up-weighted. If you're doing '-b do -p all -u all' then you should be run at a lower priority.

Comment 4

[Gregory Szorc [:gps]]

(In reply to Chris AtLee [:catlee] from comment #3)
> Mostly I'm thinking that if you're restricting your try set in some way,
> either by platform, or by test suite, or by tag, then you should be
> up-weighted. If you're doing '-b do -p all -u all' then you should be run at
> a lower priority.

Simple and effective. I love it!

For those that will complain that they really need "-b do -p all -u all" (they probably don't), I reckon we could give them a --yes-i-really-want-to-waste-resources flag if needed.

Comment 5

[Phil Ringnalda (:philor)]

It's already completely meaningless and useless, because those people who need it (and they do in fact exist) don't get OS X 10.10 (which they do in fact need) or 10.8 if they are pushing a release branch, so we should just drop support for it entirely.

There's nothing wrong with "-b do -p all -u all[incredibly,long,list,of,platforms,trying,to,get,all]", it's an expression of what someone needs to do because if you are messing with things like docshell or events you absolutely cannot predict what test suite on what platform will be the poorly written thing which will break due to its bad assumptions, but "-b do -p all -u all" should just be rejected as unsupported.

Comment 6

[(no longer active)]

(In reply to Phil Ringnalda (:philor) from comment #5)
> There's nothing wrong with "-b do -p all -u
> all[incredibly,long,list,of,platforms,trying,to,get,all]", it's an
> expression of what someone needs to do because if you are messing with
> things like docshell or events you absolutely cannot predict what test suite
> on what platform will be the poorly written thing which will break due to
> its bad assumptions, but "-b do -p all -u all" should just be rejected as
> unsupported.

Seconded.  It's counter productive to assume that everybody who pushes with -p all is just wasting resources and/or doesn't know what they are doing, and therefore penalizing them by giving their jobs less priority.