MozillaWiki

Gaia/System/Updates: Difference between revisions

Page Discussion

Gaia/System/Updates (view source)

Revision as of 06:25, 16 August 2012

8 bytes removed ,  16 August 2012
no edit summary
No edit summary
Line 29: Line 29:
* [https://bugzilla.mozilla.org/show_bug.cgi?id=780662 basecamp-update tracking bug]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=780662 basecamp-update tracking bug]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=740720  Bug 740720] - Show users a prompt to defer applying a Gecko udpate
* [https://bugzilla.mozilla.org/show_bug.cgi?id=740720  Bug 740720] - Show users a prompt to defer applying a Gecko udpate


= Gonk (Kernel) Updates =
= Gonk (Kernel) Updates =
Line 93: Line 95:
* If the user powers down the device while an update is silently downloading in background, can we resume download later on?
* If the user powers down the device while an update is silently downloading in background, can we resume download later on?
** (sicking) Necko has the ability to download ranges, but this also needs server support. We certainly could require such support though.
** (sicking) Necko has the ability to download ranges, but this also needs server support. We certainly could require such support though.


= Gecko Updates =
= Gecko Updates =
Line 200: Line 204:
** (sicking) See answer for Gonk
** (sicking) See answer for Gonk


= Gecko+Gaia: Draft process for atomic Gecko+Gaia updates =
 
 
= Gaia Updates =
 
== Introduction ==
 
* Gaia updates are related to anything that may modify the user interface and experience of the OS.  The update interval will also be every 18-weeks to align with Gecko updates.
* Updates that happen to the Core Apps (Dialer, SMS, Camera, etc.) will happen silently and users will not be charged any carrier network fees for Gaia System and Core App updates (similar to Gecko updates via a private APN). All core apps should be updated simultaneously so that a single B2G version represents the full stack.
 
== Open questions ==
 
* How much are we testing Core app updates before delivering these updates to the APN?
** This will be tested at the same level we are testing starndard 3G connectivity to the carrier network? From CLee's etherpad outline...
* Same questions from Gecko apply here:
* What is the sequence of events (eg: prompt user to restart device, whereupon install process runs?)
** How different is process from Gecko updates?
* How often should we check for updates?
* Will there be a back-up instance of Gaia in event of failed updates? If so, what will sequence of it's application be?
* Does being on 3G/Edge affect when we check for Gecko updates?
** Should not, since updates will be free OTA via Carrier's private APN.
* What—if anything—should we tell the user when a Gecko updated is detected? Should we behave differently if the user is on 3G/Edge connection when we detect that an update is available?
** Download update and apply silently in background?
* Do we have the technical ability to download the update in the background and only notify the user once the new version is available?
* Should we do anything special if the phone has been turned off for a few days and is then started?
* Do we need to have a mechanism for pushing extra-critical updates?
* Should we inform users about how big updates will be before downloading them? Do we have the ability to tell before doing the actual download?
* Do we require the user to plug in the phone if battery is below X %?
* What prompts do we present to user?
* Do we have a rollback strategy for failed installs? Previous April discussion w/ cjones indicated no...
* What is time to install? Several minutes?
* Can we avoid user friction by downloading silently, and only during periods of user inactivity? Would not want to slow down web browsing while update processed in background, for example.
* How many device reboots are required in the process?
* Do we provide link to changelog so user can review update details before installing?
* How large are these updates?
* Do we check for available device storage before downloading? If insufficient, how do we mitigate?
* If the user powers down the device while an update is silently downloading in background, can we resume download later on?
* How much user agency do we provide over installs? Can they defer? For how long? What affordances do we make for out of date Gaia + Core apps?
* How can the user review the currently-installed version? From Settings?
 
 
 
= Draft process for atomic Gecko+Gaia updates =


Josh Carpenter, Aug 15
Josh Carpenter, Aug 15
Line 418: Line 463:


After install, we can consider informing the user that the update has occurred, and offer details such as link to update details (eg: "What's new in FxOS").
After install, we can consider informing the user that the update has occurred, and offer details such as link to update details (eg: "What's new in FxOS").
= Gaia Updates =
== Introduction ==
* Gaia updates are related to anything that may modify the user interface and experience of the OS.  The update interval will also be every 18-weeks to align with Gecko updates.
* Updates that happen to the Core Apps (Dialer, SMS, Camera, etc.) will happen silently and users will not be charged any carrier network fees for Gaia System and Core App updates (similar to Gecko updates via a private APN). All core apps should be updated simultaneously so that a single B2G version represents the full stack.
== Open questions ==
* How much are we testing Core app updates before delivering these updates to the APN?
** This will be tested at the same level we are testing starndard 3G connectivity to the carrier network? From CLee's etherpad outline...
* Same questions from Gecko apply here:
* What is the sequence of events (eg: prompt user to restart device, whereupon install process runs?)
** How different is process from Gecko updates?
* How often should we check for updates?
* Will there be a back-up instance of Gaia in event of failed updates? If so, what will sequence of it's application be?
* Does being on 3G/Edge affect when we check for Gecko updates?
** Should not, since updates will be free OTA via Carrier's private APN.
* What—if anything—should we tell the user when a Gecko updated is detected? Should we behave differently if the user is on 3G/Edge connection when we detect that an update is available?
** Download update and apply silently in background?
* Do we have the technical ability to download the update in the background and only notify the user once the new version is available?
* Should we do anything special if the phone has been turned off for a few days and is then started?
* Do we need to have a mechanism for pushing extra-critical updates?
* Should we inform users about how big updates will be before downloading them? Do we have the ability to tell before doing the actual download?
* Do we require the user to plug in the phone if battery is below X %?
* What prompts do we present to user?
* Do we have a rollback strategy for failed installs? Previous April discussion w/ cjones indicated no...
* What is time to install? Several minutes?
* Can we avoid user friction by downloading silently, and only during periods of user inactivity? Would not want to slow down web browsing while update processed in background, for example.
* How many device reboots are required in the process?
* Do we provide link to changelog so user can review update details before installing?
* How large are these updates?
* Do we check for available device storage before downloading? If insufficient, how do we mitigate?
* If the user powers down the device while an update is silently downloading in background, can we resume download later on?
* How much user agency do we provide over installs? Can they defer? For how long? What affordances do we make for out of date Gaia + Core apps?
* How can the user review the currently-installed version? From Settings?




Joshcarpenter
816

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/461490"