|
|
| (28 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| {{ForceRefreshButton}}
| | #REDIRECT [[Firefox/Win64]] |
| = Firefox Desktop: Win64 =
| |
| See background summary, market analysis, goals and objectives, [[Firefox/win64/meetingarchive|here]].
| |
| == Goal ==
| |
| To Release Win64 in GA before the end of 2015 (?) in order to offer our users better experience with improvements in stability, performance, and security. Deliver these benefits in a phased roll-out and avoid the breakage for our General Audience. This means opt-in only until we are confident that we have achieved parity with Win32 for our users.
| |
| == What have we accomplished so far to reach it? ==
| |
| √ Solved test bustage<br>
| |
| √ Merged to Nightly prior to the 10th anniversary launch and rode the trains to Firefox 38 Aurora Developer Edition<br>
| |
| √ Win64 builds are currently available, [https://www.mozilla.org/en-US/firefox/developer/ here]<br>
| |
| | |
| ==Next Steps (as of Q1 2015)==
| |
| {| class="wikitable"
| |
| |-
| |
| ! Installer Payload !! Release Channel !! Date !! Notes
| |
| |-
| |
| | Full Installer || Firefox 38 Dev Edition || Launched Feb 27th || Available for language repacks only because button mechanism requires a stub installer [https://www.mozilla.org/en-US/firefox/developer/all/ Link]
| |
| |-
| |
| | Stub Installer || Firefox 38 Dev Edition || Launch Date TBD || [https://www.mozilla.org/en-US/firefox/developer/ Link]
| |
| |-
| |
| | Firefox Engineering (Decision Maker) ||
| |
| |-
| |
| | Firefox Installer Engineering || Robert Strong
| |
| |-
| |
| | Release Management || Lawrence Mandel
| |
| |-
| |
| | Release Engineering || Chris Atlee
| |
| |-
| |
| | Quality Engineering (Decision Maker)|| Robert Kaiser
| |
| |-
| |
| | Engineering Program Management || Erin Lancaster
| |
| |-
| |
| | Add Ons|| Jorge Villalobos
| |
| |}
| |
| | |
| | |
| | |
| ==Our Users & Go-To Market Plan==
| |
| | |
| ''Speaker: Javaun Moradi''
| |
| | |
| 64 bit is incredibly exciting to those of us who understand what it offers in stability, performance, and security. We're the minority. Most of the world has no idea what 64 bit means. They can already do everything they want to do online. Many will only notice 64 bit if their experience breaks. Our job is to deliver the benefits -- even if they're invisible -- and avoid the breakage.
| |
| | |
| '''Who is the user, and what problem do we aim to solve for them?'''
| |
| * Early adopters: 1%-ish Power users (gamers, developers, security folks, high memory users, etc) who know what 64 bit is and why they want it
| |
| * Everyone else:
| |
| ** Users who don't use plugins or binary add-ons and aren't at risk if we drop support
| |
| ** Users who have plugins/add-ons that may break in 64
| |
| | |
| Games industry focus: We need to show them that we’re launching 64 so that they see we’re serious, it’s coming, and they can start planning to ship games for this ecosystem (browser based games). This aligns with our objective #1. We largely suspect an announcement alone satisfies the games folks. A limited rollout to the 1% satisfies this market need and would allow them to start working.
| |
| | |
| ==== Clean Slate Approach ====
| |
| We have a chance to clean house. We recommend stopping support for most plugins. We must support Flash and Silverlight use cases, especially for streaming video. We recommend retiring binary add-on support entirely. This will wipe away a lot of browser hijacking, instability, and malware. We should reach out to top add-on developers with advance notice of our intentions. Additionally, many ESR users also rely on binary add-ons. We should broach this idea with them as well.
| |
| | |
| ==== Go to Market ====
| |
| * We'll first launch with an opt-in (new download) targeting the 1%. This puts us in the game and satisfies game developer needs.
| |
| * Limited roll out will help us gauge overall benefits in speed, stability and security and inform our decision for updating mainstream users.
| |
| * Users without legacy binary add-ons and old plugins have the next easiest migration to 64 bit.
| |
| * Auto-update for all users will be necessary at some point, but with maximum care to avoiding breakage for those running old plugins or binary add-ons.
| |
| | |
| | |
| | |
| ==== {{mplan}} Roll out Phases ====
| |
| * Phase I: Release a separate installer with 64-bit payload. Deliver to users via "what's new" page. Ensure 64-bit builds are served by default to those who choose to covert to 64-bit. Sans Flash Support. Sans the majority of binary Add-Ons.
| |
| * Phase II: Transition to Universal Installer with guidance as to the benefit of 64-bit (Flash support either via Shumway or Adobe Supported 64-bit plug-in, no wrappers). Wider add-ons support.
| |
| * Phase III: Transition to Auto Update (with opt-out for 32-bit only).
| |
| * Proposed Timing: Recommend kick-off for Fx37. Fx37 will be trunk as of 11/25 and ships on 04/07/15.
| |
| | |
| '''NB:''' We should maximize experience and lessen the chance of user breakage. It’s possible that we will find large performance gains (i.e. speed), stability gains (fewer crashes), and security gains (ASLR) in 64 bit in this 1% group that cause us to hasten auto-update to the remainder of users and give them those gains.
| |
| | |
| ==Cross-Functional Requirements==
| |
| ''Speaker: Erin''
| |
| ;RelEng & Ateam
| |
| * #1 task is Green up tests currently running on 'Date' branch before we move to m-c. Non-trivial amount of work, here and it's been ongoing: ** {{Bug|882138}}. This starts with A-Team and RelEng but doesn't stop there. Greening these tests will be highly cross-functional so there needs to be awareness and a clear priority communicated. See current tests, here: https://tbpl.mozilla.org/?tree=Date
| |
| **Additional hardware will be needed for testing. Current test runs are being done in VMs which are not sufficient for perf testing.
| |
| **The 64bit tests are also the first time we're running tests on windows VMs. So issues we see on Date could be related to VMs and could be related to 64bit (or both). From Clint "If we're serious about this effort we need at least an additional 64-bit test run on real hardware on the Date branch as well".
| |
| **Once we're happy with the date branch being green, let's roll out to m-c and then the rest of the branches.
| |
| * <s>Moving to AWS (Laura can speak to this) </s> <== For Nov 10th, let's revisit this later.
| |
| * Installer; standalone at first then moving to Universal.
| |
| ;Reliability Testing (Desktop QE)
| |
| * Achieve or exceed reliability parity with 32-bit (less than 1 crash per ~100 ADU).
| |
| * Most of our machines are 64bit capable. We don't know how representative our hardware is of the beta channel hardware we will encounter, of course (usual caveat).
| |
| * We'll need some coordination with Romanian team.
| |
| * We are adding significant complexity to update testing.
| |
| ;Perf Benchmarks
| |
| *Achieve and exceed performance parity with 32-bit. There is a games benchmark effort underway and progress being made but recommendation is to not gate on adding more perf tests and rather add them incrementally.
| |
| ;Graphics Drivers Impact
| |
| *No major impact to blacklists anticipated. From Milan, "It’s possible that WOW64 is somehow savings us from problems that we’d now start seeing with a native 64-bit Firefox, but I doubt that it would be any significant number of them." Real-world, variety testing will ultimately reveal.
| |
| ; Plug-Ins
| |
| Opportunity to be free from NPAPI. However, even w/ EME, MSE, Shumway, we may have Flash gaps (i.e. streaming media server connection / rtmp) What's the tradeoff here? Other top plugins:
| |
| *Silverlight
| |
| *Java
| |
| *Unity
| |
| *What about Media Streaming? MSE: aac, Mp4 support, and VP9
| |
| ;Add-ons
| |
| Two types of binary add-ons: js-ctypes and XPCOM. e10s will likely force deprecation of XPCOM. We need to figure out if binary compat will be maintained for the js-ctypes.
| |
| ;Metrics
| |
| *(FF Nightly active in last 45 days):35.0a1 (40% of profiles) (no missing values)
| |
| **FALSE 66.2%
| |
| **TRUE 33.8%
| |
| ;Sumo
| |
| TBD. Calling this out as something significant we'd want to work with them on.
| |
| ;l10n
| |
| No significant impact identified at this time.
| |
| ;Creative and WebDev
| |
| We will need content from them for the landing page.
| |
| ;Marketing & PR
| |
| We need to vet go-to market timing with both as well as work through potential pitfalls once this project has a greenlight.
| |
| | |
| == Issues & Risks==
| |
| ''Speaker: All''
| |
| * Are we sure that Gamers will be ok without Flash support for the first rev?
| |
| * We don't know if 64-bit Flash will be more stable than 32-bit Flash. If we ship and stability takes a nose dive, we need a mitigation plan.
| |
| | |
| == Backlog ==
| |
| <onlyinclude>
| |
| <bugzilla>
| |
| {
| |
| "blocks": "880004",
| |
| "resolution": "---",
| |
| "include_fields": "id, priority, summary, status, assigned_to",
| |
| "order": "bug_id"
| |
| }
| |
| </bugzilla>
| |
| </onlyinclude>
| |
| | |
| {| class="wikitable"
| |
| |-
| |
| ! Role !! Contact
| |
| |-
| |
| | Product Management (Decision Maker) || Javaun Moradi
| |
| |-
| |
| | Product Manager, Platform || Martin Best
| |
| |-
| |
| | Firefox Engineering (Decision Maker) || Benjamin Smedburg
| |
| |-
| |
| | Firefox Installer Engineering || Robert Strong
| |
| |-
| |
| | Release Management || Lawrence Mandel
| |
| |-
| |
| | Release Engineering || Chris Atlee
| |
| |-
| |
| | Quality Engineering (Decision Maker)|| Robert Kaiser
| |
| |-
| |
| | Engineering Program Management || Erin Lancaster
| |
| |-
| |
| | Add Ons|| Jorge Villalobos
| |
| |}
| |