1036790 - test_xrayToJS.xul will be permaorange when mozilla-central merges to mozilla-aurora on July 21st due to expecting parallel array functions that are nightly-only

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[Phil Ringnalda (:philor)]

Build current trunk with the equivalent of https://hg.mozilla.org/try/rev/e3276bd5950c (just the browser/ and config/ bits), so that nightly-only features get turned off, and parallel arrays get turned off, so filterPar/mapPar/reducePar etc. disappear, and because bug 1020609 didn't realize they go away on aurora you get test_xrayToJS.xul failing by expecting them to be exposed when they no longer exist, like https://tbpl.mozilla.org/php/getParsedLog.php?id=43493977&tree=Try

Comment 1

[Benjamin Kerensa [:bkerensa]]

(In reply to Phil Ringnalda (:philor) from comment #0)
> Build current trunk with the equivalent of
> https://hg.mozilla.org/try/rev/e3276bd5950c (just the browser/ and config/
> bits), so that nightly-only features get turned off, and parallel arrays get
> turned off, so filterPar/mapPar/reducePar etc. disappear, and because bug
> 1020609 didn't realize they go away on aurora you get test_xrayToJS.xul
> failing by expecting them to be exposed when they no longer exist, like
> https://tbpl.mozilla.org/php/getParsedLog.php?id=43493977&tree=Try

Do you think this needs tracking? Can you explain how this impacts our users?

Comment 2

[Phil Ringnalda (:philor)]

The user impact story for these "will be permaorange on the merge" bugs is "if this isn't addressed, we'll merge, the test will fail every time it is run, we will disable the test, and then we will not have test coverage for something we felt that we needed to test to prevent us from making a mistake."

In this particular case, we would be able to accidentally expose new properties to the web without having intended to, which is generally known as Breaking The Web.

But, I've traditionally (as in, for as long as tracking flags have existed) been flagging these as a courtesy notice to relman that if they aren't addressed, you're going to have a longer mergeday because after you merge, your merged tree will be broken, and you'll be chasing after people at 5 or 6 or 9pm to fix it so you can reopen. Now that you don't do merges, I guess that problem falls on... nobody? Certainly not releng, maybe sheriffs? Dicey problem, since there's no longer any one group responsible for both the decision to merge and the result of the merge.

Comment 3

[Bobby Holley (:bholley)]

Hm. So with the patch from comment 0, I get the failure, but isReleaseBuild is still false.

I'd been under the impression that RELEASE_BUILD === !NIGHTLY_BUILD, but maybe that's not the case. If it's not, we should probably also add isNightlyBuild to nsIXULRuntime.idl:

http://mxr.mozilla.org/mozilla-central/source/xpcom/system/nsIXULRuntime.idl#123

philor, does that sound right?

Comment 4

[Phil Ringnalda (:philor)]

Ugh, forgot to change my nick to "No way I'll be answering needinfo while I'm in the woods."

My understanding (from the side of I-90 in Superior, Montana, so I'm not looking it up for details) is that there's NIGHTLY_BUILD, trunk, a1 in the version number, there's RELEASE_BUILD, beta and release, no a at all in the version number, and then there's aurora, not nightly because it's a2 but not release because a2 has an a.

Comment 5

[Bobby Holley (:bholley)]

Thanks philor.

https://hg.mozilla.org/integration/mozilla-inbound/rev/41818430febe

Ryan - if this doesn't make it to inbound before tomorrow, can you make sure it gets uplifted so that it doesn't cause pain for whoever does the merge tomorrow?

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/41818430febe