Firefox/win64/meetingarchive

From MozillaWiki
< Firefox‎ | win64
Jump to: navigation, search

he 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, Jorge Villalobos, Erin Lancaster

Background Summary

Speaker: Javaun Moradi

  • 50% of Fx users on Windows run 64 bit OS. We've reached a threshold where the effort makes sense.
  • Firefox has been doing 64 bit builds for Windows for years. We once even had a 64 bit distro.
  • Development is mostly complete. Releng work is known.
  • The outstanding engineering work to complete 64 bit on Windows is: finish test coverage, plugin compat work, and installer work. The last two are significant obstacles.

Competitive Landscape

Speaker: Javaun Moradi

Objectives: Why Win64

Speaker: Javaun Moradi

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.

[DONE] What are our goals for Nov 9th Campaign?

  • Solve test bustage
  • Merged to nightly with some confidence that it would ride trains
  • No auto-updates: Need a landing page to allow users to choose a download

[PLANNED] 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.
  • Moving to AWS (Laura can speak to this) <== 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

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);


Retrieved from "https://wiki.mozilla.org/index.php?title=Firefox/win64/meetingarchive&oldid=1064722"