796347 - Have a setting to enable/disable auto updates for Gaia

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Settings, defect)

Description

[GH to BZ]

[GitHub issue by tonychung on 2012-05-25T19:53:26Z, https://github.com/mozilla-b2g/gaia/issues/1493]
For QA testing, Gaia is getting automatically downgraded to whatever is out on GAIA_DOMAIN=gaiamobile.org.   This affects QA's qualification process unless we're updating gaiamobile.org consistently or we simply turn off updates.

Can we get a checkbox or setting where we can disable and enable Gaia auto updates?   

Repro:
1) SGS2, Nexus S 5-24-2012 build
2) make flash with custom builds from release.mozilla.org/b2g
3) verify Gaia builds get downgraded, and not running the version that it was built with.

Expected:
- A checkbox to enable/disable gaia updates from gaiamobile.org would be great for QA to test against

Actual:
- check for updates is automatic if GAIA_DOMAIN=gaiamobile.org, and we get "downgraded" to whats live.   We dont necessarily want that for testing.

Comment 1

[GH to BZ]

[GitHub comment by vingtetun on 2012-05-28T11:29:10Z]
On 25/05/2012 21:53, Tony Chung wrote:
> For QA testing, Gaia is getting automatically downgraded to whatever is out on GAIA_DOMAIN=gaiamobile.org.   This affects QA's qualification process unless we're updating gaiamobile.org consistently or we simply turn off updates.
>
> Can we get a checkbox or setting where we can disable and enable Gaia auto updates?
>
> Repro:
> 1) SGS2, Nexus S 5-24-2012 build
> 2) make flash with custom builds from release.mozilla.org/b2g
> 3) verify Gaia builds get downgraded
>
> Expected:
> - A checkbox to enable/disable gaia updates from gaiamobile.org would be great for QA to test against
>
> Actual:
> - check for updates is automatic if GAIA_DOMAIN=gaiamobile.org, and we get "downgraded" to whats live.   We dont necessarily want that for testing.


Could you open an issue on bugzilla? This fix for this issue will mosty 
lives in the platform and change the behavior of the application cache. 
@cgjones and @andreasgal have some opinions on that too iirc.

Comment 2

[GH to BZ]

[GitHub comment by tonychung on 2012-05-28T16:00:23Z]
Done.  https://bugzilla.mozilla.org/show_bug.cgi?id=759126

Comment 3

[GH to BZ]

[GitHub comment by cgjones on 2012-05-29T21:49:46Z]
We should do this in the b2g build system.  Non-"release" builds should use a phony GAIA_DOMAIN.

Comment 4

[GH to BZ]

[GitHub comment by jcarpenter on 2012-06-05T08:50:18Z]
UX for this would be fairly light, I'd think. @lco, off the top of my head, an "Updates" section within Settings, under the "Device" group?

Comment 5

[GH to BZ]

[GitHub comment by lco on 2012-06-06T00:45:38Z]
yup, I was going to have one anyway :) I just need clarification on what's the default, and whether there's a manual way of searching for updates.

Comment 6

[GH to BZ]

[GitHub comment by jcarpenter on 2012-06-06T22:00:59Z]
Okay cool. 

@cyee, this is the issue I mentioned yesterday when we were discussing System updates.

Comment 7

[GH to BZ]

[GitHub comment by lco on 2012-06-07T00:17:54Z]
@tonychung, @cyee and I talked about this today, and he mentioned that he doesn't want the ability to turn off automatic updates. He can expand more on the reasons for users, but we should try to find some other way for you freeze versions for testing.

Comment 8

[GH to BZ]

[GitHub comment by cgjones on 2012-06-07T00:30:18Z]
This is driven by product requirements.  CC @cleemoz 

For testing builds, we disable gaia updates in the build system.

Comment 9

[GH to BZ]

[GitHub comment by tonychung on 2012-06-07T00:44:46Z]
@lco, @cyee, thanks for the feedback.  let me add that without a way for the user to disable updates on the device, they will currently get an update, if they are connected to wifi/phone data; and launch an app and detects if there's a difference in the app manifest.   2 concerns here:

1) for testing, we would want our beta audience to capture a snapshot of a build for a period of time, so they can effectively send us feedback on the state of the build.  If users are constantly getting updated at different times (triggered only if you connect to the network and launch the app), they may get different versions of apps in the wild very quickly.   This will make tracking issues very difficult.  It would be much nicer if we could just tell our testers to "check for updates every friday" or something, so them and us know that they are getting the same updates from the server.  then turn off the setting for a week.  

@cjones, i dont imagine we'd want to release the beta devices with our daily test builds (that include disabled updates).  i would think our testers would have the builds that we'd eventually ship with (enabled update builds, like jsconf devices)

2) beta testers in the wild, may have a mobile plan with a data cap.   We surely dont want the real users out there getting large updates against their own plan without us warning them first.   Unless we have code in there to cap downloads greater than a certain file size?   Im not sure this is worth the potential pain in ringing up someone's phone bill.

Comment 10

[GH to BZ]

[GitHub comment by cleemoz on 2012-06-07T06:37:27Z]
A couple of suggestions:

1) What if we only updated testers with weekly builds (every Wed for example) so then we should know what build users are based on when the issues was filed.  (The alternative is that all filed issues should have a tagged build so even if everyone updates at different times based on when they have network connections, you know which build they were on to debug.)

2) We will likely be able to use a separate APN for all gecko updates so network consumption and users being charged is now not a major concern.  If we can, it sounds like the team is recommending we auto-update to the latest stable build (likely not the Nightly), and if builds are tagged when issues are filed, this should help narrow down what build has the issue.

Comment 11

[Tiffanie Shakespeare [:tif]]

Going through old bugs - is this still required or can it be closed?

Comment 12

[BMO Automation]

Firefox OS is not being worked on