Meeting Notes Meetings notes from the Mozilla community

5-May-2009

Mozilla Platform Meeting Minutes: 2009-05-05

Filed under: Posts — Tags: — Benjamin Smedberg @ 11:00 pm

Platform/2009-05-05

From MozillaWiki

« previous week | index | next week »

Notices / Schedule

Firefox 3.0.11

    • code freeze tomorrow at 11:59pm
    • only a few blockers left though

Firefox 3.5 Beta 4

  • released last week
  • contains lots of great stuff
  • well received so far!

Firefox 3.5 RC1

  • code freeze for RC in late May required to hit June release window
  • while we will aim to make RC1 perfect, previous Firefox releases have needed up to 3 RCs before we’re ship-ready
  • goal is to code freeze late in the week of the 18th
    • we’ll re-evaluate then based on remaining work to do

Blocker Report

Since 1.9.1 branch …

Past 2 weeks …

[ Platform Blocker Queries | Front End Blocker Queries ]

Summary

  • slow week due to all hands
  • need to keep pressure and pace up!

The Breakdown

Browser / Front End

  • Blockers: 11 remaining & 5 nominations
    • two tricky things (undo close window fallout, tab drag and drop)
    • big props to Johnath and Dietrich for getting bug 486236 handled (again!)
  • Polish update: Firefox is 55% shiny (+2% over two weeks ago)

GFX 1.9.1 Update

  • 5 blocking bugs
    • 4 of them are image rendering related, either perf or artifacts when zooming
    • 1 is the nsWindow destroy bug, which our bandaid attempt didn’t fix

Layout Update

  • Roc is not available today
  • Layout
    • 5 blockers on trunk (3 with patches)
    • 10 untriaged noms (3 fixed)
  • SVG
    • 0 blockers
  • Video/Audio
    • 19 blockers (6 with patches) (could be pruned, should not delay our schedule)

Content Update

Mac OS X Update

JS 1.9.1

23 blockers, around 4 with patches in hand. 5 noms.

General 1.9.1

These are bugs that fall outside of components covered by the Gfx, Content, Layout and JS groups:

Mobile 1.9.1 Update

Security

Multi-Process

  • Initial docs with phases and SWAG schedule available.
  • Initial focus will be responsiveness/stability, not security sandboxing
  • We’re looking for places where chrome JS currently touches content DOM directly… see mozilla.dev.platform post for more details.

jst: “we’re going to need to remote arbitrary JS across processes to satisfy out of process plugins, so we may have the necessary machinery in place already”

  • Decisions need to be made about how to approach the network stack (should we switch to chromium’s network stack wholesale?), but I don’t know the right way to have that conversation/make that decision (it’s hard to know whether switching would reduce or extend the total time of the multiple-process work).
    • why? “because the chromium network stack and IPC stack already work well together”
    • but mapping that to existing necko API surface may be difficult

cjones: why do we want to centralize networking in the chrome process? Wouldn’t it be better to have the content processes do their own networking?
answers include: to avoid the weight of SSL/NSS in each process: to avoid complicating sharing activities for disk cache, cookies, and other shared state. we should evaluate this ourselves.

bent: we probably are going to have to make significant modifications to the Chromium IPC stack, because they use RTTI/exceptions

cjones: We should consider an IPC language, instead of a library, which we can use for typechecking and type safety, including protocol safety (e.g., read() only happens after open() and before close()).

Tree Management

  • Fixed intermittent orange on talos, Tshutdown tests enabled in talos last week, details here
  • infrastructure load for april
  • more machines coming to help deal with wait times
  • long downtime next week for firmware update on equallogic (held off from last week, and from before FF3.5b4).

Roundtable

No Comments

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress