Closed Bug 1097937 Opened 10 years ago Closed 10 years ago

disable developer edition for talos

Categories

(Testing :: Talos, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jmaher, Assigned: jmaher)

References

Details

Attachments

(2 files, 1 obsolete file)

to help prevent random spikes in talos numbers and chasing our tail, we need to turn off developer edition (via prefs).
Gijs, Do you know which prefs exactly? Also if we land this on talos trunk (v.36), would we be ok when the uplift happens? Should I uplift this to aurora as well?
Flags: needinfo?(gijskruitbosch+bugs)
It should uplift to aurora as well. I think we should ensure that these prefs: browser.devedition.theme.showCustomizeButton browser.devedition.theme.enabled are set to false. Brian, are there any others that could influence startup perf significantly that are off on release/nightly? Maybe the webide/developer tool button stuff - do you have pref IDs for those to hand?
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(bgrinstead)
(In reply to :Gijs Kruitbosch from comment #2) > It should uplift to aurora as well. I think we should ensure that these > prefs: > > browser.devedition.theme.showCustomizeButton > browser.devedition.theme.enabled > > are set to false. > > Brian, are there any others that could influence startup perf significantly > that are off on release/nightly? Maybe the webide/developer tool button > stuff - do you have pref IDs for those to hand? Here are all of the changes between dev edition and non: http://dxr.mozilla.org/mozilla-central/search?q=MOZ_DEV_EDITION&redirect=true. Here are the prefs that seem like they could possibly affect perf, and what the non-dev edition value is: app.update.badge -> false browser.devedition.theme.showCustomizeButton -> false browser.devedition.theme.enabled -> false devtools.webide.widget.enabled -> false devtools.webide.widget.inNavbarByDefault -> false devtools.chrome.enabled -> false devtools.debugger.remote-enabled -> false Alternatively, if we could somehow build without the MOZ_DEV_EDITION flag that would get everything back to normal. Panos, am I missing anything?
Flags: needinfo?(bgrinstead) → needinfo?(past)
I assume we are talking about the Aurora channel here. The latest build system changes turn on MOZ_DEV_EDITION in browser/branding/aurora/configure.sh. Could you just undo/override that?
Flags: needinfo?(past)
No, AFAIK talos tests run against the builds produced by the regular build infrastructure. We can't easily, and IMO shouldn't, change the actual builds. Changing the requisite prefs in the profile should be enough.
Assignee: nobody → jmaher
Status: NEW → ASSIGNED
Attachment #8523898 - Flags: review?(past)
past, if someone else would be a better reviewer let me know. I would like to get this in and deployed this week!
s/;/,/ - a few typos!
Attachment #8523898 - Attachment is obsolete: true
Attachment #8523898 - Flags: review?(past)
Attachment #8524680 - Flags: review?(past)
Comment on attachment 8524680 [details] [diff] [review] set preferences in talos to disable developer edition (1.1) Review of attachment 8524680 [details] [diff] [review]: ----------------------------------------------------------------- This looks fine, but I wonder if it would be prudent to undo every modification in order to be on the safe side. Other modified prefs are: devtools.theme, devtools.timeline.enabled and identity.fxaccounts.migrateToDevEdition.
Attachment #8524680 - Flags: review?(past) → review+
On the other hand if it's only browser startup we are measuring (and will be measuring in the future), then it's unlikely these other prefs will have any impact.
Talos tests page loading, window resizing, dom, javascript, startup, session restore, canvas rendering, tab animation, etc. what values should I set for: devtools.theme devtools.timeline.enabled identity.fxaccounts.migrateToDevEdition
Flags: needinfo?(past)
These are the default values in other channels: devtools.theme -> "light" devtools.timeline.enabled -> false identity.fxaccounts.migrateToDevEdition -> false
Flags: needinfo?(past)
the other patch has landed, this patch is for the 3 additional preferences.
Attachment #8525355 - Flags: review?(past)
Attachment #8525355 - Flags: review?(past) → review+
Blocks: 1101789
this is live and alerts have been generated for this. I suspect the majority of these alerts (improvements/regressions) are related to the developer tools preferences: http://alertmanager.allizom.org:8080/alerts.html?rev=fd579191bdd8&table=1
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
(In reply to Joel Maher (:jmaher) from comment #16) > this is live and alerts have been generated for this. I suspect the > majority of these alerts (improvements/regressions) are related to the > developer tools preferences: > http://alertmanager.allizom.org:8080/alerts.html?rev=fd579191bdd8&table=1 These are really odd, though - TART improved on 10.8 but got worse on 10.6 ? :-\
yeah, I was surprised by this as well. I updated aurora and beta at the same time and they were both running the same version of talos prior to the update. Beta didn't show any improvements/regressions related to my patch. There are differences in code on beta/aurora, but the biggest difference is the developer edition.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: