Once this goes green, we need to make sure that it gets seen and obeyed.

So, it turns out that this is doable directly through the tbpl interface (presumably by someone with the appropriate permissions). But philor puts it best: philor: mechanically, tree admin panel in the tree info panel; socially, to unhide a build, step zero is that it must run on try philor: unhidden means it's tier 1 and you must immediately back out for any bustage and fix the bustage outside the tree, so really try+reasonable instructions on how to run it yourself I think we're probably not quite there on that last -- if any developer at all breaks the build, they must be able to figure out how to run the tests themselves. Because this is JS-only (these builds only trigger for JS-touching changes), this isn't a huge deal, but do we at least have a wiki page we can point to that describes how to run the rooting analysis?

How is it different than the other SpiderMonkey builds?

(In reply to Phil Ringnalda (:philor) from comment #2) > How is it different than the other SpiderMonkey builds? It actually matters if it breaks. Any sort of moving GC depends on it being green, and landing that stuff (once we finish implementing it) is going to be hard enough without dealing with constantly-regressing rooting.

With https://tbpl.mozilla.org/?tree=Mozilla-Inbound&noignore=1&jobname=spidermonkey&rev=d6531ef05a6f the rooting analysis is now green on tbpl.

(In reply to Brian Hackett (:bhackett) from comment #4) > With > https://tbpl.mozilla.org/?tree=Mozilla- > Inbound&noignore=1&jobname=spidermonkey&rev=d6531ef05a6f the rooting > analysis is now green on tbpl. Red again unfortunately: Bug 778460 Moving to TBPL's component, since easier for those who care about TBPL (and thus watching its component) to know about the change. (I only stumbled across this bug by chance). Once this is ready to be unhidden, ask in-bug and myself/philor/<anyone on the sheriffpass bug> can unhide on whichever trees this is running on (just inbound and try, right?). On that note, should we get this running on mozilla-central before unhiding too? Otherwise, after an m-c -> inbound merge that turns this build red, I'll have the following options: * Hide this test again * Back out the entire merge

This is unhidden now.