700985 - The update channel shouldn't be used to determine what branch we're running

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect)

Description

[Rain [:rain1] (inactive)]

[16:45] <Standard8> IMO it is silly to use default if you're starting to get channel ifdefs in there
 [16:46] <KaiRo> the intent is to have only the nightly builds on the right channels, all intermediate builds are on "default"
 [16:47] <sid0> in that case the code is wrong
 [16:47] <sid0> the code depends on the update channel being correctly set
 [16:47] <KaiRo> all custom builds done by people in private and all Linux distro builds are also on "default", btw
 [16:47] <KaiRo> code should *never* depend on a channel
 [16:48] <sid0> sure, something has to give
 [16:48] <KaiRo> the channel is *only* there for serving the correct updates, nothing else
 [16:48] <sid0> I'll file a bug
 [16:49] <Standard8> except for extensions.checkCompatibility. ...
 [16:49] <KaiRo> and self-made, Linux disto, or "hourly" build should not get updates via our update system, so they should have the "default" channel
 [16:49] <Standard8> sid0: I'm filing the BRANCH_REGEXP one currently
 [16:49] <sid0> Standard8: ok
 [16:50] <KaiRo> Standard8: hmm, checkCompatibility is an interesting case, but I'd also feel better if it would tie to the version number ending in "a1" then to use the update channel

Comment 1

[Rain [:rain1] (inactive)]

https://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/Makefile.in#44 uses the update channel.

Comment 2

[Dave Townsend [:mossop]]

Is there an alternative?

Comment 3

[Rain [:rain1] (inactive)]

In the IRC chat log KaiRo suggested looking at the version number.

Comment 4

[Dave Townsend [:mossop]]

(In reply to Siddharth Agarwal [:sid0] from comment #3)
> In the IRC chat log KaiRo suggested looking at the version number.

That wouldn't be any use though as we intentionally want builds that developers make themselves to use the nightly form of the pref.

Comment 5

[Mark Banner (:standard8)]

I've just looked at mozilla-aurora again. The nightly builds have triggered unit tests, and the unit tests are now orange. So we're actually covered by the tests here, just not the immediate response we're used to.

Comment 6

[Dave Townsend [:mossop]]

(In reply to Mark Banner (:standard8) from comment #5)
> I've just looked at mozilla-aurora again. The nightly builds have triggered
> unit tests, and the unit tests are now orange. So we're actually covered by
> the tests here, just not the immediate response we're used to.

Yes, I'm very confused at how the original builds from the merge didn't hit problems here, they certainly should have

Comment 7

[Robert Kaiser]

(In reply to Dave Townsend (:Mossop) from comment #4)
> (In reply to Siddharth Agarwal [:sid0] from comment #3)
> > In the IRC chat log KaiRo suggested looking at the version number.
> 
> That wouldn't be any use though as we intentionally want builds that
> developers make themselves to use the nightly form of the pref.

So it's intentional that developers building a release build themselves use different code paths than an actual release or beta build? And also that Linux distros, which use the "default" channel for _all_ builds end up always using the "nightly form of the pref"? For me, both sounds like bugs.

Comment 8

[Dave Townsend [:mossop]]

(In reply to Robert Kaiser (:[e-mail]) from comment #7)
> (In reply to Dave Townsend (:Mossop) from comment #4)
> > (In reply to Siddharth Agarwal [:sid0] from comment #3)
> > > In the IRC chat log KaiRo suggested looking at the version number.
> > 
> > That wouldn't be any use though as we intentionally want builds that
> > developers make themselves to use the nightly form of the pref.
> 
> So it's intentional that developers building a release build themselves use
> different code paths than an actual release or beta build? And also that
> Linux distros, which use the "default" channel for _all_ builds end up
> always using the "nightly form of the pref"? For me, both sounds like bugs.

The latter certainly sounds like a bug, I hadn't considered what linux distros were doing, I assumed they would be following our lead to keep everything as similar as possible. The former is intentional since it is assumed that developers doing builds are going to be wanting to play with incompatible add-ons. Of course if they do builds that actually match our release builds (by setting the update channel) they will get the same behaviour as the release builds.

All of this is likely to be moot as we are probably going to remove this stuff once default to compatible is switched on.

Comment 9

[Rain [:rain1] (inactive)]

(In reply to Dave Townsend (:Mossop) from comment #8)
> The former is intentional since it is
> assumed that developers doing builds are going to be wanting to play with
> incompatible add-ons.

Maybe it's just me, but if I'm deliberately building Aurora rather than m-c, I expect the behaviour of my builds to match that of release versions of Aurora without needing to screw around with the mozconfig. That means that I'd expect to need to set the extensions.checkCompatibility pref just as I'd need to set the pref with an Aurora build I download from Mozilla.

The Addon Compatibility Reporter disables checking compat for every version anyway, and I'd expect devs to have that installed :)

Comment 10

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.