Platform/2013-05-07

« previous week | index | next week »

Actions

Notices/Schedule

• FF21.0b7(our last beta) has gone to build yesterday and will be shipped tomorrow depending on QA sign-off
• FF21.0 build# 1 RC has also gone to build last night
• Firefox 21.0 sign-offs to be held tomorrow : https://wiki.mozilla.org/Releases/Firefox_21/Final_Signoffs

Key Issues

Threads

• dev-platform
  • We should drop MathML (bjacob)
  • Follow-up: Using an inbound2 branch as a hot spare for mozilla-inbound (ryanvm)
  • clang-format (ehsan)
• dev-webapi
  • Re: Comments on the proposed DataStore API (Jose Manuel Cantera Fonesca)
• governance
  • Privacy policy update for Firefox Health Report (jmenon)

Products/Projects

Firefox OS

Firefox Desktop

Australis progress

• detailed updates in the etherpad: https://etherpad.mozilla.org/weekly-australis-checkpoint
• nearing milestone 5, "landing customization work on m-c" (bug 869104). This is a large re-work of how Firefox toolbar customization works, check out UX builds if you want a sneak peek.
• progress on tab styling continues

Performance

• 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

• • More xpcshell tests: http://gbrownmozilla.wordpress.com/2013/05/01/more-xpcshell-tests-for-android/
  • April Perf Checkup: http://gbrownmozilla.wordpress.com/2013/04/30/firefox-for-android-performance-measures-april-check-up/
  • Fx Android 4.5 stars: https://medium.com/what-i-learned-building/f4488e366b91

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 android.graphics.BitmapFactory.nativeDecodeByteArray(Native Method) at org.mozilla.gecko.AboutHomeContent/TopSitesView.getThumbnailsFromCursor(TopSitesView.java)
• Landed in Nightly: bug 864339 - Crash on 'New PrivatTab@org.mozilla.gecko.mozglue.NativeZip.createInputStream(NativeZip.java:71
• Also landed in nightly: bug 863477 - SurfaceCaps assertion failure in GLContext::UpdatePixelFormat() when playing Flash video

Stability

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

OrangeFactor

• 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!.

Performance

• First monthly performance meeting, decided on projects & goals: https://wiki.mozilla.org/Performance#Projects

Main thread I/O:

• bug 644744: Whitelist I/O that must happen before UI is shown, warn on everything else
• Running Firefox with its profile on an SD card
• bug 868441: Bypass cache when lock held too long

Fixes:

• 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:

• Julian Seward: Profiler backend news
• Avi Halchmi: Tabstrip Animation Progress
• Irving Reid: Add-On Manager Progress
• David Teller: Project "Async & Responsive" Progress
• Vladan Djeric: Running Firefox with its profile on an SD card

Metro

• 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.

Games

Mobile Web Compat

Critsmash

Memshrink

Roundtable

Build system PSA

•  :joey and :mshal from RelEng are focusing on work that :gps are initiated on migrating Makefile.in -> moz.build
  • 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.