1315083 - Create custom MAR to switch Firefox XP/Vista users to ESR52

Status: RESOLVED FIXED

(Release Engineering :: Release Requests, defect, P2)

Description

[Rail Aliiev [:rail]]

XP and 32-bit OSX build will be desupported in 53.0. We need to switch these users to ESR 52 at some point.

Comment 1

[Rail Aliiev [:rail]]

Attachment: custom_mar.tar.gz

These are the files I used to generate the MAR. It needs to be signed.

Comment 2

[Rail Aliiev [:rail]]

Nick suggested to use "add-if" instead of "add" so we can use one MAR for both platforms:

add-if "defaults/pref/channel-prefs.js" "defaults/pref/channel-prefs.js"
add-if "Contents/Resources/defaults/pref/channel-prefs.js" "Contents/Resources/defaults/pref/channel-prefs.js"
add-if "update-settings.ini" "update-settings.ini"
add-if "Contents/Resources/update-settings.ini" "Contents/Resources/update-settings.ini"

One this that I still need to figure out is the "precomplete" file. Not sure if I generated it properly. Do we even need it?

Comment 4

[Robert Strong (they/them - no direct email)]

(In reply to Rail Aliiev [:rail] ⌚️ET from comment #2)
> Nick suggested to use "add-if" instead of "add" so we can use one MAR for
> both platforms:
> 
> add-if "defaults/pref/channel-prefs.js" "defaults/pref/channel-prefs.js"
> add-if "Contents/Resources/defaults/pref/channel-prefs.js"
> "Contents/Resources/defaults/pref/channel-prefs.js"
> add-if "update-settings.ini" "update-settings.ini"
> add-if "Contents/Resources/update-settings.ini"
> "Contents/Resources/update-settings.ini"
> 
> One this that I still need to figure out is the "precomplete" file. Not sure
> if I generated it properly. Do we even need it?
Complete updates use the precomplete file to remove all of the build's files except a couple that make it possible for releng to use the same mar on release as is used to test beta updating to the release without converting the beta user to a release user.

So, it is necessary when creating a complete update.

The main thing is the files in the install directory after applying the mar must be the same as an install of the same version it has been updated to.

Comment 5

[Rail Aliiev [:rail]]

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #4)
> So, it is necessary when creating a complete update.

Does this mean that I don't need the "precomplete" files in the current scenario, when we serve a partial MAR? It is actually a complete (no "patch" directive), but the type is set to "partial". The attached tarball contains all files that I used to generate the MAR.

Comment 6

[Robert Strong (they/them - no direct email)]

You definitely don't want that precomplete! That will bust the next complete update if there are files that are no longer present in the update per comment #4.

So, you aren't generating an update that actually moves the users over to ESR and you are just changing the channel in channel.prefs.js and update-settings.ini? From there you will then need to advertise only a complete update unless you generate partials from the version they are on to the ESR version.

If you are planning a 2 update approach where you only advertise a partial to these users to get them on the channel and then only advertise a complete to actually move them over then you don't want to include the precomplete file in the partial. I think this will work but this will need to a decent amount of testing since this was never a scenario that app update was designed to support.

Comment 7

[Rail Aliiev [:rail]]

Oooh, interesting. I actually created a MAR based on the scenario in the tarball, and it seemed to work for Firefox 44:

1) Download Firefox 44.0 for Windows
2) disconnect from the Internet to make sure it doesn't update automatically
3) Install Firefox 44.0
4) switch the channel (defaults/pref/something.js) to "rail-esr-switch"
5) Connect to the Internet
6) Check for updates

Comment 8

[Robert Strong (they/them - no direct email)]

That is essentially a 2 part update as I described except the first part is done manually. 

It is possible that there are no files in 44.0 that are no longer present in whatever you updated to but that should be verified per:

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #4)
>...
> The main thing is the files in the install directory after applying the mar
> must be the same as an install of the same version it has been updated to.

Leaving the files behind won't necessarily break the build but it will prevent the uninstaller from knowing about the files and it would end up leaving files behind. Also, the precomplete file is used by the uninstaller to know which files are removed which is another reason why the precomplete file needs to be correct for the build it was created for.

If you look at the precomplete file you will also see that update-settings.ini and channel-prefs.js are not listed and should not be.

So, just don't include the precomplete file and verify that it works as expected..

Comment 9

[Chris Peterson [:cpeterson]]

XP/Vista switch will happen in bug 1318921 and bug 1318922.

Comment 10

[Rail Aliiev [:rail]]

This made me think about the migration process more. Initially I thought about a 2-step process (let's call it option A):

 1) serve a special channel-switching update to modify channel-pref.js (we don't touch this file as a part of update normally), https://bugzilla.mozilla.org/show_bug.cgi?id=1315083
 2) after switching the channel, these users will automatically update to latest ESR

We cannot open a (WNP) page in step 1) because this feature is triggered only when we bump the product version, otherwise it's ignored. Once users pass step 1) it'll be hard to distinguish them from the actual ESR population. The workaround would be (option B):

 1) set up the update server to serve updates to XP/Vista users to update let's say to 52.0.1
 2) serve the channel switch update only to 52.0.1 XP/Vista users
 3) set up the update server to serve updates to XP/Vista on ESR and with 52.0.1 build ID so they update to 52.0.2 or 52.1.0 (or anything greater) and show them the page we want them to show.

In any case this migration will require 2 steps and 2 Firefox restarts. If we want to avoid this, we need to make in-product changes to include channel-pref.js in the update archive and generate a "stealth" release with a lot of manual work... (option C) This should collapse steps 2) and 3) of option B into one.

Comment 11

[Robert Strong (they/them - no direct email)]

You could create single update mar files for each locale to go from any version to any version if you modify the scripts that create the mar to always add the channel-prefs.js and update-settings.ini files (these files are by default only added if they are missing so releng doesn't have to create additional mar files to test the release build with beta users). This would avoid the double update and wouldn't have to be a stealth release unless by stealth release you mean a non-normal release.

Comment 12

[Rail Aliiev [:rail]]

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #11)
> You could create single update mar files for each locale to go from any
> version to any version if you modify the scripts that create the mar to
> always add the channel-prefs.js and update-settings.ini files (these files
> are by default only added if they are missing so releng doesn't have to
> create additional mar files to test the release build with beta users). This
> would avoid the double update and wouldn't have to be a stealth release
> unless by stealth release you mean a non-normal release.

Hmm, wouldn't "release" Firefox reject these MAR files, because they use "esr" as the MAR channel?

Comment 13

[Robert Strong (they/them - no direct email)]

The mar file would need to specify "release" for the channel in its product information block and it would need to change the channel in the update-setting.ini so it is the same as esr.

For example:
ACCEPTED_MAR_CHANNEL_IDS=firefox-mozilla-esr

Comment 14

[Rail Aliiev [:rail]]

Yeah, that's what I thought. We'd need to generate a separate set of MAR files for the release channel (for every locale). I'd really prefer to avoid spending too much resources just to reduce the number of restarts.

Comment 15

[Robert Strong (they/them - no direct email)]

Hence why I wrote: "You could create single update mar files for each locale..."

I was just making it clear that it isn't actually required for there to be two updates to do this.

Comment 16

[Rail Aliiev [:rail]]

Morphing the title: 32-bit OSX won't be supported in ESR52.

I also found this https://hg.mozilla.org/build/braindump/file/tip/update-related/create-channel-switch-mar.py

Comment 17

[Rail Aliiev [:rail]]

Attachment: custom_mar.tar.gz

Updated the MAR to include mac-specific files and dropped "precomplete"

Published to 

https://archive.mozilla.org/pub/firefox/releases/custom-updates/switch-to-esr.mar