Closed Bug 773059 Opened 12 years ago Closed 12 years ago

Move the SpiderMonkey 'r' build out of the ignore list on tbpl

Categories

(Tree Management Graveyard :: TBPL, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: terrence, Assigned: sfink)

References

Details

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.
Depends on: 647405
No longer depends on: 647405
Depends on: 775355
Depends on: 778460
(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
Component: Release Engineering: Automation (General) → Tinderboxpushlog
Product: mozilla.org → Webtools
QA Contact: catlee
Version: other → Trunk
This is unhidden now.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Product: Webtools → Tree Management
Product: Tree Management → Tree Management Graveyard
You need to log in before you can comment on or make changes to this bug.