Temporarily force the mozilla-central revision on trunk to a known good revision for a while

RESOLVED FIXED

Status

Mozilla Messaging
Release Engineering
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: standard8, Assigned: standard8)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

We got tests broken by mozilla-central, the fix is in progress, but it may be a day or two yet (or it may be a few hours, I'm not quite sure).

In any case, we've got 3.3a3 coming up soon, and I'd like to re-open the tree. As we've not got Canary yet, our only real option is to freeze the mozilla-central revision that we're pulling.

This shouldn't be too much of a problem as Gecko 2.0 is in its last cycle and shouldn't be changing lots. We can run staging builders frequently on the latest mozilla-central revision, and if necessary, we'll just have to run hg bisect for regression hunting.

The revision I'm going to fix on is http://hg.mozilla.org/mozilla-central/rev/a9a670d16a92 - because that's the latest good revision, and 4.0b12 had some very frequent random oranges in it, so isn't really suitable.
Applied this patch locally on buildbot, windows xpcshell-tests have gone green.

diff -r 67de99bf94f6 thunderbird/config.py
--- a/thunderbird/config.py	Fri Feb 25 11:16:22 2011 +0000
+++ b/thunderbird/config.py	Tue Mar 01 14:21:07 2011 -0800
@@ -97,7 +97,7 @@
         'branch_config': 'comm-central',
         'builder_type': 'nightly',
         'factory': 'CCNightlyBuildFactory',
-        'client_py_extra_args':  ['--skip-comm', '--hg-options=--verbose --time' ],
+        'client_py_extra_args':  ['--skip-comm', '--hg-options=--verbose --time', '--mozilla-rev=a9a670d16a92' ],
         'env': {},
         'hg_branch': 'comm-central',
         'l10n_repo': 'l10n-central',
@@ -120,7 +120,7 @@
         'branch_config':  'comm-central',
         'builder_type':  'bloat',
         'factory': 'CCNightlyBuildFactory',
-        'client_py_args':  ['--skip-comm', '--mozilla-repo=http://hg.mozilla.org/mozilla-central', '--hg-options=--verbose --time' ],
+        'client_py_args':  ['--skip-comm', '--mozilla-repo=http://hg.mozilla.org/mozilla-central', '--hg-options=--verbose --time', '--mozilla-rev=a9a670d16a92' ],
         'env': {
             'XPCOM_DEBUG_BREAK': 'stack',
             'DISPLAY': ':2',

Comment 2

8 years ago
If https://bugzilla.mozilla.org/show_bug.cgi?id=636795#c33 is correct, then wouldn't temporarily setting "javascript.options.tracejit.chrome" to false also bypass the problem.
(In reply to comment #2)
> If https://bugzilla.mozilla.org/show_bug.cgi?id=636795#c33 is correct, then
> wouldn't temporarily setting "javascript.options.tracejit.chrome" to false also
> bypass the problem.

That might work, but that also means changing the build and potentially getting more issues elsewhere with jit stuff where it'd be even more difficult to track (because jit is forced off, rather than just a delayed update to the backend).
I backed this out earlier today, everything is back to normal.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.