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

Status: RESOLVED FIXED

(Mozilla Messaging Graveyard :: Release Engineering, defect)

Description

[Mark Banner (:standard8)]

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.

Comment 1

[Mark Banner (:standard8)]

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

[Joe Sabash [:JoeS1]]

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.

Comment 3

[Mark Banner (:standard8)]

(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).

Comment 4

[Mark Banner (:standard8)]

I backed this out earlier today, everything is back to normal.