834891 - Migrate win64 nightly users to win32 with a custom update

Status: RESOLVED WONTFIX

(Release Engineering :: Release Requests, defect)

Description

[Alex Keybl [:akeybl]]

Starting this off in RelEng since we should check to make sure that there are no issues around snippets for updating from 20130109030942. This build is from two days after the merge, so it's unlikely to be directly related.

Also adding qawanted to see if we're able to reproduce the update issues.

Finally, Anurag, if you have any information on the breakdown of platforms it'll help QA target their testing (especially if it doesn't match our normal platform ratio).

Comment 1

[Phil Ringnalda (:philor)]

I'd expect the platforms to be Win64, Win64, Win64 and Win64, since that's the last time we successfully built a Win64 nightly.

Comment 2

[Anurag Phadke[:[e-mail]]]

echoing :philor, based on the request_url, its "WINNT_x86_64-msvc"

Comment 3

[Alex Keybl [:akeybl]]

In bsmedberg's post "Update on turning off 64-bit Windows builds", he noted that we would "Migrate all existing users of win64 nightly channel builds to the win32 nightly channel builds via automatic update". Isn't this evidence that that never happened?

Comment 4

[Nick Thomas [:nthomas] (UTC+12)]

That got lost in all the advocacy in bug 814009.

Comment 5

[Phil Ringnalda (:philor)]

Conveniently, this morning we just built our first win64 nightly since the 9th, so now it's possible to repatriate them, since the "win64 -> win32 -> download win64 if you really wanted to stay there" path requires that there be a win64 nightly on that second day. (And if you check again after today, they should mostly have moved to a more current build.)

Comment 6

[Nick Thomas [:nthomas] (UTC+12)]

akeybl/bsmedberg, perhaps we should write a landing page to show post-update to offer some explanation ? Or even do a major update offer that has some explanation before hand ?

Comment 7

[Alex Keybl [:akeybl]]

I honestly don't have any strong opinions about Nightly and the win64 situation, since it's not released code. I just want to makes sure we're making the best use of our pre-release testing population.

People who notice/care can re-download the win64 version. I don't really think we should spend time on a landing page.

Comment 8

[Nick Thomas [:nthomas] (UTC+12)]

Ok, I think we should temporarily 
* shunt new win64 m-c snippet uploads to a different directory (which turns off win64 -> win64 updates)
* create a symlink that points WINNT_x86_64-msvc to WINNT_x86-msvc (which gives win64 requests win32 builds)

I'm going to do a little testing first to make sure we that we don't break the install when updating to win32, say by leaving some binaries around.

Comment 9

[Ed Morley [:emorley]]

Win64 installs default to C:\Program Files\ , whereas win32 uses C:\Program Files (x86)\

a) Will the new snippet be fine with using a non-standard location? (I presume so; comment 8 testing will confirm I guess)

b) Are we ok with having x86 Nightly running from the x64 location (which might lead people to not realise they have been reverted back to x86 and/or possible Windows implications)

Comment 10

[SpeciesX]

(In reply to Alex Keybl [:akeybl] from comment #7)
> People who notice/care can re-download the win64 version. I don't really
> think we should spend time on a landing page.

That will be a nice PR, if Mozilla secretly change Firefox installation without any information and choice. The next question will be, what will Mozilla change next secretly?!
This is like Facebook, which give a Fu.. about their user.

Comment 11

[Alex Keybl [:akeybl]]

(In reply to Ed Morley [:edmorley UTC+0] from comment #9)
> Win64 installs default to C:\Program Files\ , whereas win32 uses C:\Program
> Files (x86)\
> 
> a) Will the new snippet be fine with using a non-standard location? (I
> presume so; comment 8 testing will confirm I guess)
> 
> b) Are we ok with having x86 Nightly running from the x64 location (which
> might lead people to not realise they have been reverted back to x86 and/or
> possible Windows implications)

We'll definitely test (a) and the Windows implications in (b) prior to pushing out a custom snippet.

bsmedberg - when you originally proposed this, what was your thinking around updates and Program Files location?

Comment 12

[Alex Keybl [:akeybl]]

(In reply to SpeciesX from comment #10)
> (In reply to Alex Keybl [:akeybl] from comment #7)
> > People who notice/care can re-download the win64 version. I don't really
> > think we should spend time on a landing page.
> 
> That will be a nice PR, if Mozilla secretly change Firefox installation
> without any information and choice. The next question will be, what will
> Mozilla change next secretly?!
> This is like Facebook, which give a Fu.. about their user.

It's not really the same at all. Nightly is a browser development channel, and Win64 is an unreleased configuration on that channel.

Comment 13

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: diff between win32 and win64-updated-to-win32 install dirs

(In reply to Ed Morley [:edmorley UTC+0] from comment #9)
> Win64 installs default to C:\Program Files\ , whereas win32 uses C:\Program
> Files (x86)\
> 
> a) Will the new snippet be fine with using a non-standard location? (I
> presume so; comment 8 testing will confirm I guess)

I've updated a win64 build with win32 complete.mar, and the build launches and browsing seems to work fine. I diffed against a win32 install directory to come up with the attached variation, which seems pretty good (ie no binary differences or left over files). rstrong, can you comment on if the differences in uninstall.update is significant ?

Further testing I'd prefer to leave to QA. Will advise when I have a proper test set up for them.

> b) Are we ok with having x86 Nightly running from the x64 location (which
> might lead people to not realise they have been reverted back to x86 and/or
> possible Windows implications)

I don't think there's much we can actually do about this from an update point of view. IMO the key is if it causes Windows to treat the install differently or not.

Comment 14

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

(In reply to Nick Thomas [:nthomas] from comment #13)
> Created attachment 708782 [details]
> diff between win32 and win64-updated-to-win32 install dirs
> 
> (In reply to Ed Morley [:edmorley UTC+0] from comment #9)
> > Win64 installs default to C:\Program Files\ , whereas win32 uses C:\Program
> > Files (x86)\
> > 
> > a) Will the new snippet be fine with using a non-standard location? (I
> > presume so; comment 8 testing will confirm I guess)
> 
> I've updated a win64 build with win32 complete.mar, and the build launches
> and browsing seems to work fine. I diffed against a win32 install directory
> to come up with the attached variation, which seems pretty good (ie no
> binary differences or left over files). rstrong, can you comment on if the
> differences in uninstall.update is significant ?
This is generated during the update and should be fine.

btw: the precomplete file implemented in bug 386760 is what cleans up any left behind files and directories with the exclusion of the extensions and distribution directories along with the files these two directories contain.

Comment 15

[Benjamin Smedberg]

I don't think we need to worry about the different install directory for this.

Comment 16

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

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #15)
> I don't think we need to worry about the different install directory for
> this.
Agreed. It is my understanding the reason for having both a 32 and 64 bit program files directories is to lessen the likelihood of installing the same 32/64 bit program on top of the same 64/32 bit program.

Comment 17

[Alex Keybl [:akeybl]]

Great - no reason to hold on staging/testing in that case. Thanks for your input all.

Comment 18

[Robert Kaiser]

Hmm, can we have all 64bit builds before a certain build ID update to 32bit and all later ones getting 64bit updates? I guess that would be the ideal case - not sure if the update server can do that, though.

Comment 19

[Alex Keybl [:akeybl]]

(In reply to Robert Kaiser (:[e-mail]) from comment #18)
> Hmm, can we have all 64bit builds before a certain build ID update to 32bit
> and all later ones getting 64bit updates? I guess that would be the ideal
> case - not sure if the update server can do that, though.

Let me paste in bsmedberg's full proposal before moving forward:

"* Migrate all existing users of win64 nightly channel builds to the win32 nightly channel builds via automatic update.
* Continue to build win64 Nightly builds and updates on the nightly channel. Users who need the 64-bit builds will have to download it after the migration point (date TBD).
** Change the default first-run and update page for win64 builds to explain to users that they are not supported.
** Disable the crash reporter for win64 builds
** Enable click-to-play plugins by default in the win64 builds.
* Discontinue the win64 tests and on-checkin builds to reduce release engineering load. By default, do not generate win64 builds on try.
* win64 builds will be considered a “tier 3” build configuration. [1]"

So I think what this bug specifically represents are the first two bullets, and your proposal would be the ideal way forward. We can address the other bullets at a later time.

Comment 20

[Robert Kaiser]

Ah, that reminds, me - one thing that I have brought up on the crashreporter stuff is that we could (if releng can do that easily enough) put those new win64 builds (i.e. after that update cutover) onto a a different update channel like "nightly-win64" just like we do with build from development branches. That way, we could leave the crashreporter enabled as Socorro ignores that channel in the topcrash reports for Nightly, and we'd still have the reports around in case someone wants to debug something in them (e.g. if we go towards supporting it again of if some community volunteer wants to keep things going by fixing crashes). And we'd also be able to just have all those on the plain "nightly" channel to be updated to 32bit builds.

Comment 21

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to Robert Kaiser (:[e-mail]) from comment #20)
> Ah, that reminds, me - one thing that I have brought up on the crashreporter
> stuff is that we could (if releng can do that easily enough) put those new
> win64 builds (i.e. after that update cutover) onto a a different update
> channel like "nightly-win64" just like we do with build from development
> branches. 

We've not done this for a platform before, just branches as you point out, so the channel name and buildbot logic ends up getting a bit confused. Does Socorro have any config we can change to ignore Win64 in the top crash report ?

Comment 22

[Robert Kaiser]

(In reply to Nick Thomas [:nthomas] from comment #21)
> Does
> Socorro have any config we can change to ignore Win64 in the top crash
> report ?

No. That's why bsmedberg has disabling crash reporter in his proposal. I just wondered if we could navigate around that with changing the channel name. If this is too complicated or risky on buildbot, let's just go with disabling crash reporter via the mozconfig, as Benjamin proposed.

Comment 23

[[e-mail] (:bhearsum)]

Are we still going to do this? It's been a very long time, and I think there's talk of reviving win64, too?

Comment 24

[Benjamin Smedberg]

vlad mentioned that but I heard he was going to propose something to dev.planning and I haven't seen that yet.

Comment 25

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

We're reviving win64 as a target, but all the productization pieces are still very much up in the air.  We need to figure out when/if we want to do things like this (moving 32-bit users to 64-bit), how the installer will work (easier with stub), etc.

Comment 26

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Erm I misread, this is moving win64->32.  Narrowly, I think this bug specifically is probably WONTFIX at this point, since we'll be reviving official win64 support soon enough (there wasn't any discussion in dev.planning about doing that; we're just going to do it, and work is already ongoing -- the productization is the piece that's outstanding).

Comment 27

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Found in triage.

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #26)
> Erm I misread, this is moving win64->32.  Narrowly, I think this bug
> specifically is probably WONTFIX at this point, since we'll be reviving
> official win64 support soon enough (there wasn't any discussion in
> dev.planning about doing that; we're just going to do it, and work is
> already ongoing -- the productization is the piece that's outstanding).

Yes, as we're standing up 64bit windows support again, I agree it makes sense to WONTFIX this. If I've missed something, and we should still do this custom-64-to-32-update work, please reopen this bug with details.