|
|
| (88 intermediate revisions by 7 users not shown) |
| Line 1: |
Line 1: |
| = Firefox Desktop Project Review: Win64 =
| | #REDIRECT [[Firefox/Win64]] |
| The purpose of this meeting is to surface a plan and it's details in order to obtain consensus on the priority of this project and therefore, the most appropriate timing.
| |
| ==Agenda==
| |
| * Why Win64
| |
| * Our Users & Go To Market Plan
| |
| * Cross-Functional Requirements
| |
| * Issues & Risks
| |
| | |
| '''Decision-Makers:''' Johnathan Nightingale, Bob Moss, Chad Weiner, Gavin Sharp, Madhava Enros
| |
| '''Project Proposal Contributors:''' Martin Best, Javaun Moradi, Benjamin Smedberg, Clint Talbert, Laura Thomson, Lawrence Mandel, Erin Lancaster
| |
| | |
| ==Why Win64==
| |
| ''Speaker: Javaun Moradi''
| |
| * Take advantage of a limited window of opportunity in gaming and performance browser apps
| |
| * Competitive browsers
| |
| * Offer our users a better experience with improvements in stability, performance, and security. 50% of Firefox Windows users currently run 64 bit
| |
| | |
| ==Our Users & Go-To Market Plan==
| |
| ''Speaker: Javaun Moradi''
| |
| * Who is the user, and what problem do we aim to solve for them?
| |
| ** Two buckets: The 1%-ish of users who know exactly what 64 bit is and why they need it. Everyone else. They don’t know, don’t care, what 64 bit is. Unless we break something, then they’re mad at us.
| |
| ** Power users who want memory, performance, stability: Gamers, Security-minded users, Game developers and the companies they work for.
| |
| ** 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.
| |
| * Market Commentary & Questions
| |
| ** We need to hit gamers early. Most users don't care about 64, therefore tiered rollout makes sense (unless there are big performance gains, then we should go wider) but the market is tipping quickly. And eventually we need to respond w/ this superior tech.
| |
| ** There isn't a positive brand differentiation we can make here.
| |
| ** Is there a negative brand association we need to deflect if we are last?
| |
| * Go-To Market Plan
| |
| ** Phased Rollout. Why? We need to do it right. A rollout to 1% will put us on the map and satisfies game developer needs. It allows us to then assess our rollout to the remainder of users.
| |
| *** 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 03/31/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
| |
| * Green up tests currently running on 'Date' branch. 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/call to action.
| |
| **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). 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.
| |
| * Moving to AWS (Laura can speak to this).
| |
| * 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).
| |
| * Clint is double checking on number of modern 64bit machines in-house.
| |
| * We'll need some coordination with Romanian team.
| |
| * We are adding significant complexity to update testing.
| |
| ;Perf Benchmarks
| |
| *Achieve or exceed performance parity with 32-bit. Clint recommends not gating 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.
| |
| | |
| == Issues & Risks==
| |