Platform/2010-07-20

« previous week | index | next week »

Notices / Schedule

• Ideally, around September 1, we *should* be wrapping up our last beta with new features.
  • The JavaScript team is committed to that date
  • We should all be focusing on blockers until then. (There's less than six weeks left, and for previous releases, we really locked down to working on only blockers.)

Firefox 3.5.11/3.6.7

• releasing today

Firefox 3.5.12/3.6.8

• planning on shipping after BlackHat

Firefox 4 Beta 2

• code freeze happened just now
• spinning builds ASAP, hoping to have them available late today
• will get a QA estimate at tomorrow's meeting
• aiming for Friday, July 23, might slip to Monday, July 26

Firefox 4 Beta 3

• as per the Firefox Beta Plan this is due to ship on 6th of August
• code freeze scheduled for Monday, August 2 at 11:59pm PT

Blocker Report

Firefox 4

• we have 258 blocking nominations and 331 blockers:
  • beta3: 32 blockers
  • betaN: 100 blockers
  • final: 197 blockers

Browser / Front End

• The UX Team has collected and prioritized a list of Startup Experience bugs with some additional context for why they are important — take a look at the list and see if there's anything you think you can help with!

Firefox Development

• Feature complete Firefox 4
  • Gotta figure out a better way to high level this - projects page is too noisy

• Dirty profile startup
  • sdwilsh off last week - should be more updates next week.

• Jetpack API-complete for 1.0
  • 0.6 scheduled for 07-27

Platform

• GFX Goals Update:
  • Direct2D is coming along well.
    • Making progress on getting Direct2D reftest failures fixed. Tracking in bug 578110.
    • There are also a couple of perf fixes needed because of the Direct2D clipping fixes. These are in bug 576169 and bug 576170.
    • Current plan is to enable Direct2D by default only on DirectX 10-compatible hardware.
    • My handwavy plan is to aim D2D at Firefox 4 beta 4.
  • Hardware-accelerated layers have fewer updates.
    • OpenGL on GLX is coming along, with lots of fixes landing recently. It's now possible to run a full content window in OpenGL HW accelerated layers mode, and things mostly work.
    • Direct3D 9 is on the back burner while we work on Direct2D.
    • Still unscoped: running (ref)tests for HW accelerated layers.
• JS Goals Update:
  • Plan is here: https://wiki.mozilla.org/JavaScript:SpiderMonkey:PathToFirefox4
  • Fatvals landed, doing alright. Working through fuzzbugs and a few perf changes (mostly wins)
  • JM performance increases starting to land.
  • Compartments / GC work proceeding according to plan
  • ES5
    • Landings
      • JSON.stringify cycle detection no longer improperly relies on imprecise recursion-limit checking
      • arguments stringifies as "[object Arguments]"
      • [].toString and [].toLocaleString are now generic (callable on non-Array this values)
    • Current work
      • Looking into ES5 test suite failures; a decent number of tests seem to have bugs, raw failure count not meaningful yet
      • (function(){}).apply(t, args) being changed to permit non-Array args; spawned es5-discuss discussion on the exact algorithm
      • slight tightening of object-literal getter/setter syntax
      • (function(){}).bind continues
      • Duplicate property name warnings
• Content Goals Update:
  • How are we doing on the Zimbra perf tests?
• Layout Goals Update:
  • Retained layers fallout
    • A few ugly regressions, notably bug 579262, difficult because it's Flash + Windows cross-process HWND interactions
  • Where are we on content/chrome rendering integration (bug 130078)?
    • Knocking off test failures and other bugs, tn's patches are landing on mozilla-central as we go
    • Still finding new issues, so still difficult to estimate. Weeks, not days.
  • Multi-process layer backend ready to land in mozilla-central after beta2. The remaining work depends on de-widgetizing the content process completely. Not sure if we've thought through all of the implications of this WRT focus and gecko assumptions.

Windows 7 Test Status

We must have our trees green on Windows 7 to ship Firefox 4. We need owners to make this happen.

• bug 562489 [tracking bug] for the various win7 32-bit unit tests orange
• bug 562955 - jrmuizel - mochitests-4/5 - test_bug458898.html
• bug 574042, bug 574040 - Enn / jimm (toolkit / widget) widgets/test_popupincontent.xul
• bug 558403 - smontagu
• bug 578448 - Mossop - browser_bug435788.js times out
• bug 575748 - Dão Gottwald - browser_overflowScroll.js
• bug 562967 - Justin Dolske - test_uriloader_exthandler\unit\test_handlerService.js
• bug 562957 - Enn

Direct 2D oranges:

• bug 578110 - [tracking bug] reftest Direct 2D oranges
• bug 578127 - no assignee - bidi/visualmarquee.html, logicalmarquee.html
• bug 578134 - no assignee -box-shadow/boxshadow-rounded-spread.html
• bug 578135 - no assignee -box-shadow/boxshadow-onecorner.html
• bug 578114 - no assignee -bugs/289480.html#top
• bug 578116 - no assignee -379349-1b.xhtml, 379349-1c.xhtml
• bug 578118 - no assignee -385569-1a.html, 385569-1b.html
• bug 578121 - jrmuizel -456219-1{a,b,c}.html, 456219-2.html
• bug 578124 - jrmuizel -555388-1-ref.html

Tree Management

• Changing TryServer to *not* run Talos by default. [1]
• Discussion about using same changeset for nightlies. If you have opinions, chime in here [2]

• Re-enabling 10.6 unittests on tryserver bug 579887
• Switching unit tests from builders to minis
  • disabling TrackeMonkey unit tests on builders this week
  • enabling this week unit tests on minis for Fedora (32/64-bit) and 10.5/10.6 for *all* remaining project branches
  • we are not going to run unit tests on minis on 1.9.1/1.9.2 branches since it would require a great deal of backporting of the perma-oranges fixes. Branch tests will continue to be run on builders.
• Windows 64-bit
  • switched from VS2010 to VS2008 to have jemalloc support
• Automated cleaning of old builds on stage.m.o [ https://wiki.mozilla.org/ReleaseEngineering:StageCleanupPolicy https://wiki.mozilla.org/ReleaseEngineering:StageCleanupPolicy]

• Important dev.tree-management threads:
  • Turning off talos by default on Try: http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/4bfd23ddd2533be4#
  • Using the same revision across platforms on for nightly builds: http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/98d2431051edc7bd/ab52557e6009f7b7?lnk=raot#ab52557e6009f7b7

Roundtable

• beta 2 roundup (beltzner)
• beta 3 planning (beltzner)
• pushes without linux tests (Mossop)
• What makes it hard to diagnose and fix random oranges? Are any teams or people interested in taking on the pain points we have identified? -Jesse
• bsmedberg proposed that the tree stay restricted to blockers-only until we branch.
  • And that we shouldn't branch until Jaegermonkey lands
  • Certainly can't branch until dewidgetification and XP-layers lands
• Unified template library -- mozilla/tl?