From MozillaWiki
Jump to: navigation, search

« previous week | index | next week »

Platform Meeting Details

  • Tuesday 2013-05-07 - 11:00 am Pacific
  • Dial-in: Audio-only conference# 98411
    • People with Mozilla phones or softphones please dial x4000 Conf# 98411
    • US/Toll-free: +1 800 707 2533, (pin 4000) Conf# 98411
    • US/California/Mountain View: +1 650 903 0800, x4000 Conf# 98411
    • US/California/San Francisco: +1 415 762 5700, x4000 Conf# 98411
    • US/Oregon/Portland: +1 971 544 8000, x4000 Conf# 98411
    • CA/British Columbia/Vancouver: +1 778 785 1540, x4000 Conf# 98411
    • CA/Ontario/Toronto: +1 416 848 3114, x4000 Conf# 98411
    • UK/London: +44 (0)207 855 3000, x4000 Conf# 98411
    • FR/Paris: +33 1 84 88 37 37, x4000 Conf# 98411
    • Gmail Chat (requires Flash and the Google Talk plugin): paste +1 650 903 0800 into the Gmail Chat box that doesn't look like it accepts phone numbers
    • SkypeOut is free if you use the 800 number
  • Engineering Vidyo Room / Warp Core / SFO-Boardroom / Tor Commons
  • join #planning for back channel



32 bugs (37 bugs last week)
13 bugs (27 bugs last week)
Unresolved Aurora 54 Trackers (non-security, not tracked for Beta) Unresolved Beta 129 Trackers (non-security)

Key Issues



Firefox OS

Firefox Desktop

Australis progress
  • Drew landed the background tab thumbnailing service. Uses a remote browser to capture thumbnails without main-thread impact (bug 841495).
  • The JS Internationalization API has been enabled (bug 853301); there may still be some issues to work through, but people should start experimenting with it now

Firefox Mobile

Blog shout out
Usability, Responsiveness, and New Features
  • We stopped packaging a whole ton of files as part of the multi-locale builds. If you see any regressions, please file a bug and CC :Pike. bug 792077, bug 848297
  • Fixed regressions to async canvas updates bug 863223
  • Add a force override preference for Reader Mode availability on low-mem devices landed in Fx23 bug 852417
  • Dynamic Toolbar is being disabled for Fx22 but is still enabled for Fx23 so please keep on using it so we can make it great!
Stability Wins
  • Uplifted to Fx22 Bug 863288 - java.lang.OutOfMemoryError: at Method) at org.mozilla.gecko.AboutHomeContent/TopSitesView.getThumbnailsFromCursor(
  • Landed in Nightly: bug 864339 - Crash on 'New PrivatTab@org.mozilla.gecko.mozglue.NativeZip.createInputStream(
  • Also landed in nightly: bug 863477 - SurfaceCaps assertion failure in GLContext::UpdatePixelFormat() when playing Flash video


  • Nothing this week, we look decent on all channels right now (we need people to work on the harder, long-term issues, of course).


  • Past week's OrangeFactor: 7.63 (Previous Week: 7.31).
  • No significant changes from last week.
  • bug 858948 (frequent Windows mochitest-2 leak) still needs an owner. Previous attempts have failed.
  • bug 866470 (ASSERTION: Should not be trying to paint a background color if we don't have one: 'drawBackgroundColor' in layout/reftests/bugs/289480.html) is recent, frequent, and un-owned.
  • 15 intermittent failures fixed in the last week - List - Thanks!.


Main thread I/O:


  • bug 852467: nsDisableOldMaxSmartSizePrefEvent runs on the gecko main thread, blocks for long periods of time
  • bug 649216: Remove unnecessary delay when clicking tab close buttons sequentially
  • bug 699331: Reduce impact of font name enumeration at startup

Blog posts:


  • Although Metro work is riding the trains, it's all behind an ifdef (MOZ_METRO) which is only turned on in Nightly.
  • Current expected work complete date for v1 is November 19th, although it has been moving up due to faster velocity in the recent iterations (so it may move up more).
  • Tier 1 status? No, but we will be. The main step in progress towards this is releng work to turn on mochitests (bug 864418).
  • Waiting for OMTC to land for a bunch of panning/zooming work.
  • Other than OMTC, largely what's remaining for v1 work is front end work.
  • Most of the progress from the Metro team is in the form of front end work.
  • Elm users (Where Metro development began) have been migrated from elm to m-c.
  • Software updates through the Metro interface, will be offered trough the about flyout and silently in the background.
    • Some changes for that included upgrading while another browser from the same install is open.
  • May 13th - May 17th will be the 2nd Metro work week in the Vancouver office.
  • Sprint 5 and sprint 6 were recently completed, and Sprint 7 is in progress.


Mobile Web Compat




Build system PSA

  •  :joey and :mshal from RelEng are focusing on work that :gps are initiated on migrating ->
    • bug 847009
    • what other pain points are you hitting with the build system? PGO? universal builds? tests? please get in touch with Joey, Mike or Gregory

Should we switch from hg to git?

It's becoming more and more clear that the version control system of choice for open source development these days is git. The question is, should Mozilla engineering switch from Mercurial to Git?. As most people already know, lots of Mozilla hackers already use git for various types of work, and some of our significant projects also already use git (Gaia, Rust, Servo, etc). Lots of Gecko hackers also already use git for their work on mozilla-central, through various conversions from hg to git.

One inevitable question that this raises is whether we're also switching to hosting Gecko development on Github, and the answer to that question is no. We've been in talks with Github, but we will not get the reliability guarantees we need nor the flexibility we need if we were to host Gecko development on Github, i.e. Github issues not being powerful enough, pull request data outside of our control, etc).

As for switching the source control system from hg to git, here's some of the benefits:

  • Simplified on-boarding, people generally know git, but generally don't know hg.
  • We already mirror hg to git (in more than one way), git is already a necessary part of most of our lives and unifying our tools where we can is a good thing.
  • Branches! The ability to have "everything you want" in a single local repository (independently of how the repositories are hosted remotely). I.e. m-c, aurora, beta, release, user repositories, project branches and more as needed, no matter where the different branches are hosted.
  • No need for multiple local repositories, many working directories per repository.
  • Simplifies the path for better review tools and change workflows.
  • Opens the door for a pull-request like model for accepting changes.
  • Better merge algorithms, no more orphan patches that no longer apply cleanly.
  • Easier collaboration through shared branches.
  • Full history, all of hg and CVS!
  • OMG interactive rebase (squashing, removing, reordering, editing commits)
  • ZOMG git add --patch (selective change committing for splitting changes into multiple commits).
  • Works well with github, even though we're not switching to github as the ultimate source of truth.

Some of the known issues with doing this are:

  • New tool to learn for those who have not already needed to learn it.
  • Performance of git on windows is sub-optimal (we're already working on it).
  • Need to incorporate git into our windows build tools.
  • Lots of infrastructure work needed to make this switch.

The next step here is to take this discussion to the newsgroups to get feedback and make sure that everyone affected by this have a chance to weigh in before we decide whether we should make this switch. There's a lot of systems that depend on this outside of engineering. Identifying and switching all those systems from hg to git will be a significant amount of work that we'll need to measure and take into consideration here before we make any final decisions.