In preparation for moving linux64 debug tests in TaskCluster to Tier 1, we first need to move the build to Tier 1. There are a couple of issues that need to be sorted out first (see dependencies of bug 1242556), but we'd like sheriff input on anything else that might be required. Sheriffs, please comment on whether the current Tier 2 TC linux64 debug build job meets Tier 1 job visibility requirements.

please note :philor mentioned clobberer support is a must have.

(In reply to Joel Maher (:jmaher) from comment #1) > please note :philor mentioned clobberer support is a must have. yeah fine for me so far, but yeah clobber support is really something we need

Planning to do this March 23rd. Who on the TH side can make the visibility policy change then?

(In reply to Selena Deckelmann :selenamarie :selena from comment #5) > Planning to do this March 23rd. Who on the TH side can make the visibility > policy change then? This is something the sheriffs should do; you can ask Wes or Tomcat, depending on what time it is.

At Selena's request, I removed trunk trees from the "tier-2 - tc desktop/android" exclusion profile, which I think will do what we want to do.

(In reply to Wes Kocher (:KWierso) from comment #7) > At Selena's request, I removed trunk trees from the "tier-2 - tc > desktop/android" exclusion profile, which I think will do what we want to do. On second thought, this might actually move all TC build jobs to tier-1, not just linux64. Tier changes only apply to newly ingested pushes/jobs, so I'll need a new push to a trunk tree to see if that's what happened. Leaving a ni on myself to make sure I fix it if it's screwy.

It indeed wasn't set correctly. I believe I've set it correctly starting with bz's push near the top of https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&fromchange=8786bbb9702f&tochange= edba1116e87e&group_state=expanded&filter-searchStr=tc%20(b) There are now two tier-2 exclusion profiles: "Tier 2 - TC Desktop/Android (Firefox47- Edition)" currently applies to non-trunk trees, and DOES include the Linux64 TC build jobs. "Tier 2 - TC Desktop/Android (Firefox48+ Edition)" currently applies only to trunk trees, and does NOT include the Linux64 TC build jobs. As Firefox 48 works its way to release, we'll need to remove trees from the 47- list and add them to the 48+ list, until 48 hits release (and maybe even the yet-to-be-made ESR52), at which point we can get rid of the 47- list entirely.

Aren't taskcluster jobs able to set their own tier in the data that they report to treeherder, so we could just have the job that's supposed to be tier-1 on the trees where it's supposed to be tier-1 say it is, and have the other jobs say that they are tier-2, and not go through all this?

I see these as tier-1 :) Should we mark the buildbot build jobs as tier-2 now?

(In reply to Phil Ringnalda (:philor) from comment #10) > Aren't taskcluster jobs able to set their own tier in the data that they > report to treeherder, so we could just have the job that's supposed to be > tier-1 on the trees where it's supposed to be tier-1 say it is, and have the > other jobs say that they are tier-2, and not go through all this? I don't know. I thought this was something that TH folks wanted to control. We're happy to do it in a push!

(In reply to Selena Deckelmann :selenamarie :selena from comment #12) > (In reply to Phil Ringnalda (:philor) from comment #10) > > Aren't taskcluster jobs able to set their own tier in the data that they > > report to treeherder, so we could just have the job that's supposed to be > > tier-1 on the trees where it's supposed to be tier-1 say it is, and have the > > other jobs say that they are tier-2, and not go through all this? > > I don't know. I thought this was something that TH folks wanted to control. > We're happy to do it in a push! There's some confusion about that. Cam, Ed, sheriffs, do we want submitters to be able to set their own Tier status, or do we want to reserve that for sheriffs?

They are setting it, and have been setting it since last June, bug 1174192. Sheriffs can still override it, as the b2g->tier-3 thing showed, when the b2g jobs that marked themselves as tier-2 wound up tier-3 because of the tier-3 exclusion profile. Sheriffs never have had the exclusive right to gatekeep tier-1, because jobs always have and still do show up as tier-1 unless the job itself says it is something other thant tier-1 or someone manually, awkwardly, haltingly and annoyingly marks it as tier-2 or -3 after it is already running. And assuming that we actually do want to have taskcluster linux64 debug being tier-1 ride the Gecko 48 train (not entirely clear to me that we do, since it appears to be running fine on aurora and my memory of the blockers was that they were all infra support rather than anything in-tree), this is a perfect situation for the job to deal with its own tier, since having an exclusion ride the trains is a miserable PITA and relies on sheriffs remembering in the heat of mergeday that they need to do something they haven't thought about for six weeks.

To clarify how it currently works: It goes through these checks to see where it belongs. The last one that is true wins: 1. tier setting (default 1) 2. Tier-2 profile 3. Tier-3 profile So: - job{tier: 1} but belongs in to Tier-2 profile == Tier-2 - job{tier: <not set>} and NOT in a profile == Tier-1 - job{tier: 2} and NOT in a profile == Tier-2 - job{tier: 1} but belongs in BOTH the Tier-2 and Tier-3 profiles, == Tier-3 In short, Sheriffs can always win with Tier-2 and Tier-3, but they can't force Tier-1 at this time.

We've made the visibility change, and I've opened a new bug to track defining exactly the process we'll use going forward.