Closed Bug 961275 Opened 10 years ago Closed 10 years ago

Add a TBPL browser build to GGC

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla31

People

(Reporter: terrence, Unassigned)

References

Details

It would be helpful to have a browser version of SM(ggc) to keep it building and to have a reputable source for up-to-date binaries. There are also some brave (some might say foolhardy) individuals that want an easy way to try out a GGC enabled browser before we ship.
Would this be running tests as well?
I think so, but needinfo'ing terrence to make sure.
Flags: needinfo?(terrence)
Let's do this, with tests if possible.  Tests are currently green on linux with a few assorted failures on other platforms - see bug 764882 for details.
OK, then we'll probably want to implement this in the TBPL UI like we have ASAN builds implemented. File a bug in Webtools::Tinderboxpushlog when you're ready to move on that and I can help.
It would be great to get a ggc build + tests running on m-i and feeding trees, if it is possible and we have the releng resources for it. We tried a ggc branch before, but it was soaking a relatively large fraction of our time keeping it synced with m-i since there were only two of us. With three I'm not sure the situation is much better.
Flags: needinfo?(terrence)
On second thought, most of our merge pain was because we were doing exact rooting in the twig. Now that we are basically stable (1) merging should be much easier in general and (2) we could continue to land on m-i and just have one patch enabling ggc on the twig. Daily rebases should be trivial and we wouldn't need to re-merge into m-i since we aren't landing code there. It wouldn't tell us what patch regresses ggc, but it would help us get stable in general.
Given the temporary nature of this situation, a twig sounds like the best option to me as well.
And we are successfully building on Maple now, thank you for the advise, Ryan!

By chance, do you happen to know how to change the update channel? It looks like there were several moving pieces here: the buildbot-configs repo sets the configdir, which configure.in uses to choose a mozconfig, then the mozconfig sets the channel as desired. But now all of that machinery has been removed for twigs and the mozconfig looks at the MOZ_UPDATE_CHANNEL environment variable, which is normally not set. I'll look more today unless someone knows who I should query.
Not sure offhand, sorry. Try asking in #releng.
And we're landed now.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
You need to log in before you can comment on or make changes to this bug.