1126837 - (mozorg-win64) Make Fx38 Win64 build of Dev Edition Available on moz.org

Status: RESOLVED FIXED

(www.mozilla.org :: General, defect)

Description

[Erin Lancaster [:elan]]

(we can move this to a different component as needed, want to file under Dev Tools in case there are any other technical requirements). This will be for Fx38 which will be Aurora as of 02/24). 

We'll need to pull what will be Aurora Fx38 from ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-aurora/

and we'd like it to be available for install via:
https://www.mozilla.org/en-US/firefox/developer/
https://www.mozilla.org/en-US/firefox/developer/all/ 

or have it be available on it's own page, see bug 1075973. 

Next steps:
- Be certain there aren't any technical requirements or bugs we need to fix for Fx38
- Connect with Jen and team to see if a project brief is needed/what is required to move this request forward
- Define exactly when GoLive will be 
- Connect with Rebecca in Metrics to be sure instrumentation is defined and a plan in pace

Comment 1

[Jennifer Bertsch [:jbertsch]]

Thanks, Erin.  I've flagged this bug for Pmac and Josh, asking them to comment regarding any changes that might be required in Bouncer.

A project brief is not required if we can just use the download button on /firefox/developer.

A project brief is required if it needs a stand along download page.  I don't think we have capacity to design and build a stand alone download page for Win64 in time for GDC given prioritization of other projects.

Comment 2

[Erin Lancaster [:elan]]

Sounds great, thank you.

Comment 3

[Josh Mize [:jgmize]]

We'll need a platform and product created in Bouncer first, which I believe is just an entry in the admin without any code changes, and then we can add it to https://github.com/mozilla/bedrock/blob/master/bedrock/mozorg/helpers/download_buttons.py

Comment 4

[Jennifer Bertsch [:jbertsch]]

Hi Erin-

Could we please have final info for making the Win64 build available for install via the Dev Edition landing page 5 business days before the launch date?

Is Feb 24 the launch date?

Thx,
Jen

Comment 5

[Jennifer Bertsch [:jbertsch]]

One more question, Erin (+Arcadio).

Will there be two Win versions of Dev Edition going forward?  One 64 and one 32?

Comment 7

[Erin Lancaster [:elan]]

:jbertsch, allow me me to obtain consensus on Go Live and then plan for future releases. GoLive would either be 02/24 OR the week of GDC along with the rest of our PR announcements. The answer to the second question should be 'yes' but I need to be sure Engineering and QE are good with this.

Comment 8

[Jennifer Bertsch [:jbertsch]]

(In reply to Erin Lancaster [:elan] from comment #7)
> :jbertsch, allow me me to obtain consensus on Go Live and then plan for
> future releases. GoLive would either be 02/24 OR the week of GDC along with
> the rest of our PR announcements. The answer to the second question should
> be 'yes' but I need to be sure Engineering and QE are good with this.

Perfect!  Thanks :elan!

Comment 9

[[e-mail] (:bhearsum)]

(In reply to Erin Lancaster [:elan] from comment #7)
> :jbertsch, allow me me to obtain consensus on Go Live and then plan for
> future releases. GoLive would either be 02/24 OR the week of GDC along with
> the rest of our PR announcements. The answer to the second question should
> be 'yes' but I need to be sure Engineering and QE are good with this.

I highly doubt we're dropping the 32-bit version anytime soon. Certainly not right away, because we don't have a transition plan yet for moving people from the 32-bit to the 64-bit version.

Comment 10

[Erin Lancaster [:elan]]

Right, we'd have both 32-bit and 64-bit options.

Comment 11

[Erin Lancaster [:elan]]

We have sign off from QE in terms of pre-release quality so yay on that. There are some strategic things happening with partners so I need until Wed of next week to provide a GoLive date. 

Is that ok?

Comment 12

[Jennifer Bertsch [:jbertsch]]

Yes!  That is fine - as long as we have at least 5 business days.  Thanks!

Comment 13

[[e-mail] (:bhearsum)]

bug 1124819 is about RelEng support for win64 on Beta/Release, so this bug isn't involved at all - updating dependency list.

Comment 14

[Erin Lancaster [:elan]]

:jbertsch, decision is made: GoLive =  02/24. NI to ctalbert so QE can do one last sanity check, prior. Thank you very much and let me know if there are any other questions!

Comment 15

[Kohei Yoshino [:kohei]]

I have already prepared a pull request for this, on the top of Bug 1129624.

https://github.com/kyoshino/bedrock/compare/kyoshino:bug-1129624-refactor-download-links...bug-1126837-win64

Comment 16

[Jennifer Bertsch [:jbertsch]]

(In reply to Kohei Yoshino [:kohei] from comment #15)
> I have already prepared a pull request for this, on the top of Bug 1129624.
> 
> https://github.com/kyoshino/bedrock/compare/kyoshino:bug-1129624-refactor-
> download-links...bug-1126837-win64

Thanks, Kohei!

NI for pmac and jgmize to review the PR.

Comment 17

[cmtalbert]

Kairo, let's make sure that our SV team takes a look at the build from the dev-edition landing page and verifies that it downloads the 64bit build. I don't think we need much testing on the builds themselves (there is a lot of automation for this) but ensuring the plumbing works and we get the build we expect to get would be a good thing. Thanks.

Comment 18

[Robert Kaiser]

Florin, as just mentioned in our meeting, forwarding this ni? to you for comment #17. Once this bug is marked fixed (next week, comment #14 says Feb 24th) we want to make sure the download point to the right builds. We expect those new links to go to Dev Edition 38 64bit builds.

Comment 19

[Paul [:pmac] McLanahan]

on it.

Comment 20

[Sören Hentzschel]

What's about Firefox Beta x64? Bug 1129602 was about Developer Edition and Beta. Bug 1129602 was marked as duplicate of this bug, but this bug seems only to be about Developer Edition. Is there a different bug for the Beta?

Comment 21

[Kohei Yoshino [:kohei]]

Attachment: pull request

Comment 22

[Jennifer Bertsch [:jbertsch]]

(In reply to Erin Lancaster [:elan] from comment #14)
> :jbertsch, decision is made: GoLive =  02/24. NI to ctalbert so QE can do
> one last sanity check, prior. Thank you very much and let me know if there
> are any other questions!

Hi Erin-

Is there going to be a press release or any other announcements around this?  Is there a specific time on Tuesday it needs to be live?

Thx,
Jen

Comment 23

[Erin Lancaster [:elan]]

No press release. We're using this as sugar on the icing for other announcements happening for GDC but nothing devoted to Win64 on that date. Thank you.

Comment 24

[Kohei Yoshino [:kohei]]

Firefox 38 Developer Edition will be released this Friday. Are we going to push this tomorrow anyway? The Aurora win64 links are now enabled (Bug 1125923 Comment 8) but still pointing 37.

Comment 25

[Erin Lancaster [:elan]]

:kohei, best to keep it in lock step with the 32-bit version of Firefox 38 Dev Edition. No need to push the 64-bit version early.

Comment 26

[Erin Lancaster [:elan]]

:KaiRo: ^ see above, can we get a Go/No-Go from QE by Noon Pacific on Thursday?

Comment 27

[Paul [:pmac] McLanahan]

:elan, we really prefer to avoid pushing changes to mozilla.org on Fridays if we can help it. Would it be okay if this change went out late Thursday?

Comment 28

[Erin Lancaster [:elan]]

:pmac, absolutely. The only deadline we're driving to is Day 1 of GDC which is March 2nd. Thank you!

Comment 29

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

(In reply to Erin Lancaster [:elan] from comment #26)
> :KaiRo: ^ see above, can we get a Go/No-Go from QE by Noon Pacific on
> Thursday?

Erin, we're going to verify this on our side. I think 2 days should be enough to verify this with a couple of people, so you should have the Go/No-Go by Noon Pacific on Thursday IF we get the test page(s) set up by the end of the day today, otherwise we would be left with just 1 day of testing which would cut it rather close.

Erin could you please let us know:
- what pages should we verify?
- when will we have the test pages set up?

Comment 30

[Erin Lancaster [:elan]]

:FlorinMezei

1) We need to sanity check Thursday's Firefox Dev Edition 38.0a2 as soon as it's available Thursday AM (en-us and if you want to choose another language or two, that's great) from FTP: ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-aurora/ and let us know in this bug ticket that we're good to go (no sudden regressions, crashes or data loss which would block a Dev from basic use = minimum quality bar).

2) The release pages in question are: 
https://www.mozilla.org/en-US/firefox/developer/
https://www.mozilla.org/en-US/firefox/developer/all/ 

3) NI to :pmac to help connect us to where we can find staging URLs (maybe moz.org QA has this covered but since this is kind of out of band request, please lean on :FlorinMezei to help if that makes life easier).

Thank you!

Comment 31

[Paul [:pmac] McLanahan]

None of our pre-production servers have the code to support the 64bit Dev Ed on them yet. We're waiting to merge that code to our master branch until closer to time we're allowed to push it. If you need a place to test we can put it up on one of our demo servers. The code works fine now for 37 when tested locally. So if it can go live at any point I can merge it to master and it will show up on our dev server (www-dev.allizom.org), and then I can manually push it to our staging server (www.allizom.org) if you want. Otherwise I'll get a development instance up. Just let me know.

Comment 32

[Erin Lancaster [:elan]]

:pmac, let's do whatever the usual process is (this is new to me). If the code works fine locally, no need to add extra steps. As long as QE finds that there isn't a new issue in Fx38 Aurora and the links post to the correct build, we're good. Thank you!

Comment 33

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Note that testing the Thursday AM Aurora 38 Win x64 builds is not a viable option, since we are based in Romania, and that would mean end of day Thursday for us. However, my understanding is that this is about making the builds public, so there should be no real difference between the current latest Aurora and tomorrow's. Given this, we've started today doing some basic smoke testing on the latest Aurora 38, to make sure there is no major breakage. I'll post the final results here. Testing details are available at: https://etherpad.mozilla.org/Fx38AuroraWinx64.

Note that according to comment 17 we were expecting to also validate the landing page to see that we get the correct builds. In other words, we were expecting a demo page that would show the Win 64 builds, where we could download the builds from, and check that we get the correct builds. In comment 31, Paul seems to imply that this would not really be needed. We would need a final decision here whether this is or isn't necessary. If this is necessary, then we need the demo environment set up and communicated to us by end of day today (US time), as tomorrow would be the last day when we can do this testing.

Erin, can you please review my comments above and let us know:
- is the smoke testing for current Aurora 38 builds ok? We think that should be enough.
- do we need to test download of builds from a demo Aurora landing page?

Comment 34

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

One other thing to note here is: since bug 604967, Win x64 builds are only supported for Windows 7+ versions, and will not work on older versions. I don't know if this was taken into account, but I think we should clearly specify this on the new Aurora landing page.

Comment 35

[Paul [:pmac] McLanahan]

I don't think we have any indication on the page of minimum OS requirements. NI jbertsch to flag this.

Comment 36

[Paul [:pmac] McLanahan]

Also Florin and Erin, I'm still missing something. I understand that Dev Edition 38 is what is being tested and will be released this week. But there are currently 64bit Dev Ed 37 builds available in bouncer. So what I'm saying is that we can push the changes to the site at any point and the links will work for 64bit Dev Ed even before 38 is released. So if we want the site to be ready we can do it like that. Otherwise we can wait for 38 to be released then merge and push the changes to show the 64bit builds.

Comment 37

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

(In reply to Paul McLanahan [:pmac] from comment #36)
> Also Florin and Erin, I'm still missing something. I understand that Dev
> Edition 38 is what is being tested and will be released this week. But there
> are currently 64bit Dev Ed 37 builds available in bouncer. So what I'm
> saying is that we can push the changes to the site at any point and the
> links will work for 64bit Dev Ed even before 38 is released. So if we want
> the site to be ready we can do it like that. 

That sounds good to me. Let's see what Erin thinks.

Comment 38

[Robert Kaiser]

(In reply to Florin Mezei, QA (:FlorinMezei) from comment #33)
> - is the smoke testing for current Aurora 38 builds ok? We think that should
> be enough.

For this bug, we don't need the smoketesting at all. For the usual Sign-off to turn on updates on Aurora/DevEd, we need those, but no need to report in this bug.

> - do we need to test download of builds from a demo Aurora landing page?

All that this bug is about is the links to downloads. The testing we need specifically for this bug is:
1) Do https://www.allizom.org/en-US/firefox/developer/ and https://www.allizom.org/en-US/firefox/developer/all/ contain the download links for the 64bit builds?
2) Do those downloads correctly result in 64bit versions of Developer Edition 38 being installed?
3) Do those installations start up correctly?

If all three of those questions can be answered with "yes", we are done with QE for this specific bug, in my view.

The smoketesting etc. should be handled via our usual channels and plans, just that we have 64bit Windows in there as an additional platform.

Comment 39

[Robert Kaiser]

(In reply to Paul McLanahan [:pmac] from comment #31)
> None of our pre-production servers have the code to support the 64bit Dev Ed
> on them yet.

We'll need to have the versions of the websites that are going to get deployed up on either www-dev.allizom or even better www.allizom up before Florin can do any testing specifically for this bug here. And as he said, they'll need things to be up during the normal European work day for their testing to be done.
Paul, is it possible to get those site changes up on dev or even staging in time so they can at least do that testing tomorrow?

Comment 40

[Paul [:pmac] McLanahan]

(In reply to Robert Kaiser (:[e-mail]) from comment #39)
> Paul, is it possible to get those site changes up on dev or even staging in
> time so they can at least do that testing tomorrow?

It's possible, yes. However, doing so will block our ability to push out any other changes, so if this needs to happen on staging then it needs to be coordinated and happen quickly so we can get it into production shortly there after.

I'm also a bit confused on why this needs to happen on staging? Typically we don't do initial testing on stage. Staging is for testing the deployment, not the code. We have demo servers if you'd like to see how it'll work in an environment very much like production. I understand that bouncer and the builds need a lot of testing, but changes to mozilla.org aren't necessary for those tests. Also this is something we've done before for Linux 64bit builds. Is there something about this time that is special?

Comment 41

[Robert Kaiser]

(In reply to Paul McLanahan [:pmac] from comment #40)
> I'm also a bit confused on why this needs to happen on staging? Typically we
> don't do initial testing on stage. Staging is for testing the deployment,
> not the code. We have demo servers if you'd like to see how it'll work in an
> environment very much like production.

Oh, basically, I don't care where we exactly have it as long as we have the exact code that will be shipped and can test that it does the right thing end-to-end. So whatever is fine to you, as long as you can give us access to see whatever will be on https://www.mozilla.org/en-US/firefox/developer/ and https://www.mozilla.org/en-US/firefox/developer/all/ and have us test that, that's what I'm looking for. I somehow thought this would be staging, I guess I was wrong.

Comment 42

[Paul [:pmac] McLanahan]

(In reply to Robert Kaiser (:[e-mail]) from comment #41)
> Oh, basically, I don't care where we exactly have it as long as we have the
> exact code that will be shipped and can test that it does the right thing
> end-to-end.

Wonderful! I've just deployed the branch to our demo4 server:

https://www-demo4.allizom.org/en-US/firefox/developer/

Let me know if you encounter any issues there. I've done some spot checks and things seem fine, though I don't have a 64bit windows system to test.

Comment 43

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

I had a quick look at the demo pages: 
- https://www-demo4.allizom.org/en-US/firefox/developer/all/ 
     * shows the Win x64 links, and the few ones that I've tried seemed to download the proper builds for x64, just for Aurora 37 - is it ok to continue with this?
- https://www-demo4.allizom.org/en-US/firefox/developer/
     * the "FREE DOWNLOAD" buttons on the page point to the Aurora 37 32-bit stub installer (firefox-37.0a2.en-US.win32.installer-stub.exe) - I don't see a stub installer for Win x64 so I wonder whether this will just be limited to the 32 bit stub installer, or we should also have one for x64

Comment 44

[Jennifer Bertsch [:jbertsch]]

(In reply to Florin Mezei, QA (:FlorinMezei) from comment #34)
> One other thing to note here is: since bug 604967, Win x64 builds are only
> supported for Windows 7+ versions, and will not work on older versions. I
> don't know if this was taken into account, but I think we should clearly
> specify this on the new Aurora landing page.

Hi Florin and Pmac-

The download button will detect and correctly install a Win64 or Win 32 build for the user w/out the user taking action, correct?

Florin - Are you suggesting that we need to explicitly tell folks that they won't get the Win64 build if they are on a Win32 machine?  Will this be covered in the Dev Edition release notes?

Thx,
Jen

Comment 45

[Paul [:pmac] McLanahan]

(In reply to Florin Mezei, QA (:FlorinMezei) from comment #43)
> I had a quick look at the demo pages: 
> - https://www-demo4.allizom.org/en-US/firefox/developer/all/ 
>      * shows the Win x64 links, and the few ones that I've tried seemed to
> download the proper builds for x64, just for Aurora 37 - is it ok to
> continue with this?

That's how it should work for now. It will show dev edition 38 when product-details is updated for 38.

> - https://www-demo4.allizom.org/en-US/firefox/developer/
>      * the "FREE DOWNLOAD" buttons on the page point to the Aurora 37 32-bit
> stub installer (firefox-37.0a2.en-US.win32.installer-stub.exe) - I don't see
> a stub installer for Win x64 so I wonder whether this will just be limited
> to the 32 bit stub installer, or we should also have one for x64

Are you testing from a 64bit windows OS? I believe it's supposed to offer you the most appropriate build for your OS (as good a guess as it can make from what the UA string tells it). And I believe for 64bit there is not yet a stub installer in bouncer (and possibly not one on FTP). Kohei pointed out in the pull-request that the 64bit stub installer is being worked on in bug 797208.

Comment 46

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

(In reply to Jennifer Bertsch [:jbertsch] from comment #44)
> The download button will detect and correctly install a Win64 or Win 32
> build for the user w/out the user taking action, correct?

I tested on Win 7 x64, and the download button downloaded the Aurora 37 32-bit stub installer. However, I guess there's not much else it could do since it seems we do not yet have a 64-bit stub installer (as Paul pointed out in comment 45, and there isn't one on FTP). The only way the button could serve a 64-bit installer would be if it would link to the 64-bit full installer which we do have. 

> Florin - Are you suggesting that we need to explicitly tell folks that they
> won't get the Win64 build if they are on a Win32 machine? 

That's not what I meant actually. Win 64 builds do not install on Win x64 versions lower than Windows 7. You get an error stating that the minimum requirement is Windows 7. However, you get the error only when you start to install the build. I was thinking that maybe we should inform the users that Windows 7 is the minimum requirement for Win 64 builds (either this or detect the OS and not offer Win 64 builds for x64 versions lower than Win 7... I guess the first option would be much easier to implement).

Comment 47

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

(In reply to Paul McLanahan [:pmac] from comment #45)
> Are you testing from a 64bit windows OS? I believe it's supposed to offer
> you the most appropriate build for your OS (as good a guess as it can make
> from what the UA string tells it). And I believe for 64bit there is not yet
> a stub installer in bouncer (and possibly not one on FTP). Kohei pointed out
> in the pull-request that the 64bit stub installer is being worked on in bug
> 797208.

I was testing on Windows 7 x64, but indeed there is no stub installer for x64 on FTP. I believe we might want to up the priority of bug 797208, as it seems it's still considered low priority.

Comment 48

[Jennifer Bertsch [:jbertsch]]

Hi Florin-

Do you mean we need to call out that Firefox only support Windows 7 64 bit and not Windows XP or Vista 64 bit?

Thx,
Jen

Comment 49

[Jennifer Bertsch [:jbertsch]]

(In reply to Florin Mezei, QA (:FlorinMezei) from comment #47)
> (In reply to Paul McLanahan [:pmac] from comment #45)
> > Are you testing from a 64bit windows OS? I believe it's supposed to offer
> > you the most appropriate build for your OS (as good a guess as it can make
> > from what the UA string tells it). And I believe for 64bit there is not yet
> > a stub installer in bouncer (and possibly not one on FTP). Kohei pointed out
> > in the pull-request that the 64bit stub installer is being worked on in bug
> > 797208.
> 
> I was testing on Windows 7 x64, but indeed there is no stub installer for
> x64 on FTP. I believe we might want to up the priority of bug 797208, as it
> seems it's still considered low priority.

Pinging Erin to help with this one.

Comment 50

[Robert Kaiser]

(In reply to Paul McLanahan [:pmac] from comment #45)
> That's how it should work for now. It will show dev edition 38 when
> product-details is updated for 38.

That means we are unable to test the website reasonably before everything is live. We want to verify that people get to working 64bit 38 versions, so we need to point there for us to be able to test.

> Are you testing from a 64bit windows OS?

I think we also should make sure we offer the 64bit version when people are on WOW64, i.e. currently using a 32bit version on a 64bit Windows.

Comment 51

[Paul [:pmac] McLanahan]

(In reply to Robert Kaiser (:[e-mail]) from comment #50)
> That means we are unable to test the website reasonably before everything is
> live. We want to verify that people get to working 64bit 38 versions, so we
> need to point there for us to be able to test.

I disagree. What you'll see on the website is that we simply link people to bouncer (download.mozilla.org). Once that is done www.mozilla.org is out of the picture. We can verify that the proper links to bouncer are being generated. For the main buttons the links are to the "latest" product in bouncer. This will change to 38 as soon as bouncer is updated and mozilla.org has nothing to do with that. For the buttons that refer to a specific build version (like those on the /all page) you should be able to test the builds coming from bouncer by requesting the proper version from bouncer as soon as it's available. If we really must test these pages with a full download and install of Firefox (which to my knowledge we've never done, even for large releases of the release channel) we can do so on staging just before we do the final push to production of this code after product-details and bouncer have been updated.

> I think we also should make sure we offer the 64bit version when people are
> on WOW64, i.e. currently using a 32bit version on a 64bit Windows.

Agreed. I think that's how it's supposed to work. I'm NIing Kohei to double check.

Comment 52

[Robert Kaiser]

(In reply to Paul McLanahan [:pmac] from comment #51)
> (In reply to Robert Kaiser (:[e-mail]) from comment #50)
> I disagree.

I understand all that, but it means we are unable to do any end-to-end testing before 38 is live on the Aurora channel during European work time.

Comment 53

[Paul [:pmac] McLanahan]

(In reply to Robert Kaiser (:[e-mail]) from comment #52)
> I understand all that, but it means we are unable to do any end-to-end
> testing before 38 is live on the Aurora channel during European work time.

Then I guess my question is; what makes this release special? I've been helping with Firefox releases on the web side for at least a couple years now and have never encountered this.

Comment 54

[Robert Kaiser]

(In reply to Paul McLanahan [:pmac] from comment #53)
> Then I guess my question is; what makes this release special?

I don't know, I've never been involved in this part of things before. But maybe that's the difference. I see the issue, though, in that you only point to bouncer, and it's up to bouncer to serve the right thing. I guess that means we will only be able to test this once bouncer points to 38.

Comment 55

[Johannes Pfrang [:johnp]]

https://www-demo4.allizom.org/en-US/firefox/developer/  - 
The Download-Button links to the win32-stub in IE x32 and Chrome x32 and to the win64-full on Chrome x64 and Nightly x64. AFAIK the latter two can only be installed on Win7+, so the links are "safe", in a way that we don't link to x64 for possibly unsupported configurations. The downside is that we don't link to win64 for e.g. a Firefox 32-bit running on Win8 x64. Normally we should be able to find such upgrade scenarios by looking at the "Windows NT"-Substring in the User-Agent.

Comment 56

[Erin Lancaster [:elan]]

Thanks for bearing with, Everyone. I've been in conversation with QE and I've walked through the user experience on a Windows 8 system and here's a refined plan/ask: 

1) The ideal situation for: https://www-demo4.allizom.org/en-US/firefox/developer/ would be to have *two* buttons, one for 32-bit and one for 64-bit. The current single button user experience isn't granular enough. As it stands, the user experience feels like we're replacing Win32 and we can't do that right now. I can file a separate bug to cover 2 buttons (not on this current deadline for GDC). Please hold on including Win64 via this entry point until further notice. 

2)  For GDC, https://www-demo4.allizom.org/en-US/firefox/developer/all is perfect because there are specific buttons and the user can take deliberate action and choose between Win32 and Win64.

Next Steps (please correct as needed): 
0) 02/26: Goes Live https://www-demo4.allizom.org/en-US/firefox/developer/all (NO Win64 avail via https://www-demo4.allizom.org/en-US/firefox/developer/ unless it's a separate button to full Win64 installer).
1) 02/25-02/27: QE is currently running smoke tests; once those are complete, they will give a go/no-go to RelMan by 02/27.
2) 02/27 RelMan will update and push product details with bumped version 
3) 02/27 QE will verify the links are correct:
/developer/ = Win32 only
/developer/all = Win32 and Win64
Version = 38.0a2
Build = firefox-38.0a2.en-US.win64.installer.exe (I leave it to them to sort out testing other language packs)

I hope this makes sense!

Comment 57

[Paul [:pmac] McLanahan]

Just for full clarity, there is another page with a Dev Edition button:

https://www-demo4.allizom.org/en-US/firefox/channel/#developer

I'm assuming this should work like /firefox/developer/ for this release and stick with 32bit only?

Comment 58

[Paul [:pmac] McLanahan]

We don't currently do separate buttons for 64bit builds of any kind. Our buttons detect the best build from the info we can gather and present that one along with a link to go get any other kind or localization we have. We could do separate buttons, but it would be a major rework of how they're done, and pages like /firefox/channel/ would be pretty crowded with buttons for 2 desktop builds and 1 android (and another soon for iOS). My vote would be to stick with suggesting a single build based on detectable machine specs and go from there. I believe (and the UX people should chime in here) that if we present these 2 options when this reaches beta or release that it will negatively impact installs since most people have no idea how to answer the 32 vs. 64 bit question. People downloading Dev Edition are more likely to know I'd guess, but it'll still probably result in people downloading the wrong one.

Comment 59

[Paul [:pmac] McLanahan]

(In reply to Johannes Pfrang [:johnp] from comment #55)
> The downside is that we
> don't link to win64 for e.g. a Firefox 32-bit running on Win8 x64. Normally
> we should be able to find such upgrade scenarios by looking at the "Windows
> NT"-Substring in the User-Agent.

That is unfortunate. We try to take in all the data we can when detecting browser and platform specs. This is done in site.js [0] so the issue is likely there. We'll see how we can improve. Would you mind providing navigator.userAgent and navigator.platform strings of the 32bit Fx you were using?

[0] https://github.com/mozilla/bedrock/blob/5bcae2ab1bcdd78b11aa4b00f7b3ad5cf7a06340/media/js/base/site.js

Comment 60

[Kohei Yoshino [:kohei]]

Yes, the button should detect win64 but looks like those two things are missing: 

1. WOW64 detection
2. Windows 7+ detection - :johnp has a patch

I'll update my pull request shortly.

Comment 61

[Johannes Pfrang [:johnp]]

(In reply to Kohei Yoshino [:kohei] from comment #60)
Feel free to incorporate / change my patch as you like, as I was not quite sure how to name things properly. I skipped WOW64 detection, because I was not entirely sure if that should also be captured archSize or if that would mess up something. archSize sounds to me like CPU architecture size and the comment also mentions "64-bit [...] processor", so maybe just adding WOW64 to the regex there may be enough.

Comment 62

[Erin Lancaster [:elan]]

(In reply to Paul McLanahan [:pmac] from comment #57)
> Just for full clarity, there is another page with a Dev Edition button:
> 
> https://www-demo4.allizom.org/en-US/firefox/channel/#developer
> 
> I'm assuming this should work like /firefox/developer/ for this release and
> stick with 32bit only?

Yes, please. 32-bit only.

Comment 63

[Erin Lancaster [:elan]]

(In reply to Paul McLanahan [:pmac] from comment #58)
> We don't currently do separate buttons for 64bit builds of any kind. Our
> buttons detect the best build from the info we can gather and present that
> one along with a link to go get any other kind or localization we have. We
> could do separate buttons, but it would be a major rework of how they're
> done, and pages like /firefox/channel/ would be pretty crowded with buttons
> for 2 desktop builds and 1 android (and another soon for iOS). My vote would
> be to stick with suggesting a single build based on detectable machine specs
> and go from there. I believe (and the UX people should chime in here) that
> if we present these 2 options when this reaches beta or release that it will
> negatively impact installs since most people have no idea how to answer the
> 32 vs. 64 bit question. People downloading Dev Edition are more likely to
> know I'd guess, but it'll still probably result in people downloading the
> wrong one.

Thank you for confirming what is/isn't possible. Good call on consulting with UX, we will do just that in preparation for Beta and GA as part of the larger GTM plan. Thank you for the support pmac and team! Give me until after GDC to post back with an update either in this bugzilla ticket or one(s) covering beta/GA.

Comment 64

[Kohei Yoshino [:kohei]]

(In reply to Erin Lancaster [:elan] from comment #62)
> (In reply to Paul McLanahan [:pmac] from comment #57)
> > Just for full clarity, there is another page with a Dev Edition button:
> > 
> > https://www-demo4.allizom.org/en-US/firefox/channel/#developer
> > 
> > I'm assuming this should work like /firefox/developer/ for this release and
> > stick with 32bit only?
> 
> Yes, please. 32-bit only.

Updated my pull request to disabled win64 download buttons for now. It's just 2 lines of CSS code.

Comment 65

[Kohei Yoshino [:kohei]]

(In reply to Sören Hentzschel from comment #20)
> What's about Firefox Beta x64? Bug 1129602 was about Developer Edition and
> Beta. Bug 1129602 was marked as duplicate of this bug, but this bug seems
> only to be about Developer Edition. Is there a different bug for the Beta?

The minute says 37.0b2, coming next Tuesday, will be the first Beta to support win64.

https://wiki.mozilla.org/Firefox/Channels/Meetings/2015-02-24#RelEng

Comment 66

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Basic Smoke testing is pretty much complete and looks good, with only one issue under investigation (bug 1136796). Detailed test results can be found at https://etherpad.mozilla.org/Fx38AuroraWinx64.

In the mean time I also did some additional testing today on the landing pages, with Windows 7 x64 and found out the following:

1. All links still point to 37 Aurora builds.

2. Download buttons on ".../developer/" and ".../channel/#developer" behave the same.

3. Downloading from Chrome 32-bit on the en-US page (https://www-demo4.allizom.org/en-US/firefox/developer/), will download the 32-bit en-US stub installer. 

4. Downloading from Chrome 32-bit on a localization page (https://www-demo4.allizom.org/ro/firefox/developer/), will download the 32-bit full installer. Note that there are 32-bit stub-installers for locales on FTP, but only the en-US page downloads the stub-installer.

5. Downloading from Firefox Nightly 64-bit on the en-US or a localization page (https://www-demo4.allizom.org/en-US/firefox/developer/), will download the correct 64-bit full installer.

6. https://www-demo4.allizom.org/en-US/firefox/developer/all/
a) all Win64 links are the Win64 correspondent to the Win32 links (and all are full installers) - en-US is the only exception where we get the stub-installer for Win32, and the full installer for Win64
b) could correctly download Win64 builds for each link
c) installed and started en-US & rm Win64 builds => all worked well

7. On Windows Vista x64, Chrome 32-bit shows no links to download 64 bit builds.

Testing details are available at https://etherpad.mozilla.org/Fx38AuroraWinx64 (bottom half of the document).

So it seems we do in fact detect 64-bit and the Windows version, but I'm not sure that all of the results above are the desired ones. Please review them and let me know if we need to verify something else.

Comment 67

[Robert Kaiser]

(In reply to Paul McLanahan [:pmac] from comment #58)
> We don't currently do separate buttons for 64bit builds of any kind.

Windows is different from any other platform that we have in this regard (and not just because it's >90% of our market).
We cannot send 64bit builds by default to *any* Windows users at this point from the default single download button like this. We can only offer them optionally. The /all page looks fine as it is, and for now, we should only offer the 64bit builds from there at all given we can't do an optional second button on the main page.

So, we (QE) can not sign this off at all right now as long as the main page default button points to Win64 for anyone at all.

Comment 68

[Kohei Yoshino [:kohei]]

(In reply to Robert Kaiser (:[e-mail]) from comment #67)
> So, we (QE) can not sign this off at all right now as long as the main page
> default button points to Win64 for anyone at all.

The download buttons is detecting the platform version so the win64 builds are only offered to users on win64, as Florin's test result 3 to 5 shows.

I have solved 2 detection issues in my GitHub pull request: WOW64 support and minimum requirements (Windows 7) check. The code is not yet deployed to the demo4 server. I'll ping :pmac on IRC.

But as Erin says this time we offer the win64 builds only on /firefox/developer/all/. So I have disabled the win64 download button on /firefox/developer/ and /firefox/channel/#developer. The code is not yet deployed to the demo4 server. Once deployed, Florin's test result 5 will be different, as everyone continues to download the win32 builds.

Comment 69

[Paul [:pmac] McLanahan]

I've deployed Kohei's latest changes to demo4. Please test again. You should no longer be automatically offered a 64bit build.

Comment 70

[Paul [:pmac] McLanahan]

(In reply to Florin Mezei, QA (:FlorinMezei) from comment #66)
> 1. All links still point to 37 Aurora builds.

Known. Won't change until release.

> 4. Downloading from Chrome 32-bit on a localization page
> (https://www-demo4.allizom.org/ro/firefox/developer/), will download the
> 32-bit full installer. Note that there are 32-bit stub-installers for
> locales on FTP, but only the en-US page downloads the stub-installer.

We don't do FTP on the site. We only send the product and OS desired to bouncer which sends you to the appropriate URL for a file. Seems like the "firefox-aurora-latest-l10n" product needs updating in bouncer if there is a stub available. Not sure of the proper component but we should file a separate bug for that.

Comment 71

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

(In reply to Paul McLanahan [:pmac] from comment #69)
> I've deployed Kohei's latest changes to demo4. Please test again. You should
> no longer be automatically offered a 64bit build.

Re-tested on Windows 7 x64, by verifying the download buttons with Firefox Nightly x64, on:
- https://www-demo4.allizom.org/en-US/firefox/developer/
- https://www-demo4.allizom.org/ro/firefox/developer/
- https://www-demo4.allizom.org/en-US/firefox/channel/#developer
- https://www-demo4.allizom.org/ro/firefox/channel/#developer

The download buttons now behave same as on Chrome 32-bit, by offering the Win32 stub-installer for en-US and the Win32 full installer for ro. https://www-demo4.allizom.org/ro/firefox/developer/all/ still shows the correct links, so things look good.

Comment 72

[Martin Best (:mbest)]

We should like circle back to this later now that we have a solution for right now.  My thinking is that we need to be mindful of what different audiences need depending on channels.  My stab at this is that it should look like.

Nightly: user has choice 32-bit and 64-bit, mainly developers that need to test
Dev: user has choice 32-bit and 64-bit, mainly developers that need to test
Beta: One button based on what's best for their platform, more general audiences, devs need a way to find 32bit.
Release: One button based on what's best for their platform, very general audiences, devs need a way to find 32bit.

The assumption here is that we really want people to start moving over to 64-bit.

Just wanted to note that we need to nail down this strategy as we will want to push this to release 38-39 time frame depending on the latest plan is sitting.

Comment 73

[Robert Kaiser]

(In reply to Kohei Yoshino [:kohei] from comment #65)
> The minute says 37.0b2, coming next Tuesday, will be the first Beta to
> support win64.

FWIW, that only means that we will *build* 64bit for 37 starting with b2, but there are no plans to expose it on websites for beta so far. That will happen when 38 goes to beta at the earliest, which is in 5 weeks.

Comment 74

[Robert Kaiser]

(In reply to Martin Best (:mbest) from comment #72)
> The assumption here is that we really want people to start moving over to
> 64-bit.

I'm not sure that assumption is correct at this stage, esp. as we do not know yet how well the number of plugins work that are flying around on users's computers (remember that 32bit plugins only work in 32bit Firefox). I agree with your list once we are 100% comfortable with 64bit - until then, I personally feel better with leaving beta/release point to 32bit on that one button and have 64bit available on the "other systems and languages" page. I agree for Nightly/Aurora, though.

Comment 75

[Martin Best (:mbest)]

(In reply to Robert Kaiser (:[e-mail]) from comment #74)
> (In reply to Martin Best (:mbest) from comment #72)
> > The assumption here is that we really want people to start moving over to
> > 64-bit.
> 
> I'm not sure that assumption is correct at this stage, esp. as we do not
> know yet how well the number of plugins work that are flying around on
> users's computers (remember that 32bit plugins only work in 32bit Firefox).
> I agree with your list once we are 100% comfortable with 64bit - until then,
> I personally feel better with leaving beta/release point to 32bit on that
> one button and have 64bit available on the "other systems and languages"
> page. I agree for Nightly/Aurora, though.

Agreed.  My point is more we need to be clear on what we are doing and when we are switching over.  We should be ready to talk about this publicly so that plugins have time to move adjust.  Without some expectation setting, we will get stuck in limbo between the two version and we need to make sure this path is hammered out.  A task for after GDC and MWC. ;)

Comment 76

[Robert Kaiser]

(In reply to Martin Best (:mbest) from comment #75)
> Agreed.  My point is more we need to be clear on what we are doing and when
> we are switching over.  We should be ready to talk about this publicly so
> that plugins have time to move adjust.  Without some expectation setting, we
> will get stuck in limbo between the two version and we need to make sure
> this path is hammered out.  A task for after GDC and MWC. ;)

Agreed on all counts.

Comment 77

[Martin Best (:mbest)]

Just to be clear, we have not commitment to ship at the moment, there are other dependencies that must be met for us to do that.  I do want to be ready the moment they clear so thinking this through is what I'm after rather than pushing for release before said dependencies are cleared.

Comment 78

[Kohei Yoshino [:kohei]]

So... this bug is WONTFIX for now?

Comment 79

[Erin Lancaster [:elan]]

(In reply to Kohei Yoshino [:kohei] from comment #78)
> So... this bug is WONTFIX for now?

No, I recommend this bug will be RESOLVED FIXED once the Win64 Buttons go live, here: https://www.mozilla.org/en-US/firefox/developer/all/ 

See Comment 56.

NI to KaiRo so he can resolve this ticket once it's verified (we're shooting for today, Fx38 Aurora was about 1/2 through smoke testing yesterday afternoon pacific time).

Comment 80

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Basic Smoke testing was completed (see https://etherpad.mozilla.org/Fx38AuroraWinx64). The only remaining issue is bug 1136796, where some memory measurements were provided. I'm not sure whether the bug is a blocker or not for releasing this.

Comment 81

[Erin Lancaster [:elan]]

Florin and KaiRo, I'd say we need to continue to investigate bug 1136796 and get this actionable on part of engineering in due time before aurora merges to beta but at this point, let's not block.

Comment 82

[Erin Lancaster [:elan]]

QE has signed off on 38.0a2. FYI so now it's up to RelMan to notify RelEng and bouncer will be updated. Not sure of ETA but we're good. FYI to anyone following at home.

Comment 83

[[github robot]]

Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/d53c5782af7d3f55544514737ee38bae7c00b51c
Fix Bug 1126837 - Make Fx38 Win64 build of Dev Edition Available on moz.org

https://github.com/mozilla/bedrock/commit/ba75e5be34ebd6dce6f1516b192ad1f1d5dad334
Merge pull request #2754 from kyoshino/bug-1126837-win64

Fix Bug 1126837 - Make Fx38 Win64 build of Dev Edition Available on moz.org

Comment 84

[Erin Lancaster [:elan]]

Double checking, when will this go live? https://www.mozilla.org/en-US/firefox/developer/all/

I see that the 38.0a2 version seems to be in bouncer since it shows up: https://www-demo4.allizom.org/en-US/firefox/developer/all/

I have a new request to make sure this goes live by Monday about 6AM pacific, is that possible?

Comment 85

[Kohei Yoshino [:kohei]]

This should be live later today along with MWC stuff.

Comment 86

[Erin Lancaster [:elan]]

++ That would be most appreciated. :)

Comment 87

[Erin Lancaster [:elan]]

Thank you, Kohei!!

Comment 88

[Paul [:pmac] McLanahan]

Yup. We're pushing staging server now. Should be live within the hour.

Comment 89

[Paul [:pmac] McLanahan]

All changes are live in production.

Comment 90

[Erin Lancaster [:elan]]

Looks good! Thank you so much for your support this week. Firefox Platform and Dev Tools team really, really appreciate it.

Comment 91

[Robert Kaiser]

(In reply to Erin Lancaster [:elan] from comment #79)
> NI to KaiRo so he can resolve this ticket once it's verified

Florin will verify today if the download from the page gives the right build and it installs and launches fine. For that, forwarding this ni? to him. Once we have that, I'll consider QE done here. :)

Comment 92

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Tested today and got the exact same results as the last time I tested this (comment 71), just this time I was served DevEdition 38 as expected. I downloaded a few builds and installed/launched a few (en-US 32-bit stub, ro 32-bit full, eu 64-bit full) and everything worked fine. There is no problem that I could find.

I saw that we do not have all languages for all pages, but I suppose this is not an issue (e.g. we have romanian for "/firefox/channel/#developer" but not for "/firefox/developer/").

Comment 93

[alainez]

(In reply to Jennifer Bertsch [:jbertsch] from comment #5)
> One more question, Erin (+Arcadio).
> 
> Will there be two Win versions of Dev Edition going forward?  One 64 and one
> 32?

Removing NI