Platform/2008-12-16

From MozillaWiki

« previous week | index | next week »

Details

• Tuesday – 11:00am Pacific, 2:00pm Eastern, 19:00 UTC

• Mozilla Building S – <script> conference room
• 650-903-0800 or 650-215-1282 x92 Conf# 8605 (US/INTL)
• 1-800-707-2533 (pin 369) Conf# 8605 (US)
• irc.mozilla.org #shiretoko for backchannel

Notices / Schedule

Beta 3

• notable dates:
  • String freeze is December 31st, 11:59pm PDT (happy new year)

  • Code freeze is January 13th, 11:59pm PDT
  • QA Start is January 15th, 9:00am PDT
  • Release is targeted at January 26th

Blocker Report

• Platform blocker queries

• 3.1 blocker queries
• blockers are trending down nicely, still seeing a lot of non-blocker activity through approvals, though – also note these numbers are for FIXED on trunk, not fixed1.9.1 (47 blockers need 1.9.1 landing!)
• nominations are trending up – need to stay on top of this triage

Firefox 3.1 Update

• 53 Firefox 3.1 blockers
  • 8 Blockers to be fixed for Beta 3 (P1)

  • 11 Blockers to be fixed for RC (P2)
  • 15 unassigned blockers
  • 5 need 1.9.1 landing
  • see also these other triage queries

• Polish update: Firefox is 16% shiny
  • 13 of 57 easy polish bugs fixed (whiteboard [polish-easy])

  • 2 of 33 hard polish bugs fixed (whiteboard [polish-hard])

GFX 1.9.1 Update

• GFX blocking 1.9.1+

• GFX wanted 1.9.1+
• A bunch of imglib blockers went in and bounced out last week, joe’s on it
• Have patches for half of blockers, trying to land those soon and get to other half

Layout 1.9.1 Update

• Layout blocking1.9.1+

• Blocker counts
  • SVG 6

  • Video/Audio 19
  • Rest of layout 31
  • Just handful of really serious non-fuzz bugs (outside of Video/Audio)

Content 1.9.1 Update

• Content blocking1.9.1+

JS 1.9.1

• Focusing on blockers. Down to 37.

Mobile 1.9.1 Update

General 1.9.1 Updates

Security

Security Reviews

Still outstanding / to be scheduled

• Javascript Tracing

• native JSON
• DNS prefetching
• elliptical border-radius

Booked but not yet completed

Roundtable

• QA would like to remind developers to mark their bugs fixed1.9.1 when they land them on the branch, as then QA can go along and verify them.
  • see “blocker report”, above, for a list of bugs that might actually be fixed on 1.9.1 but not have the keyword set!

• Proposal: use fixed1.9.2 and verified1.9.2 for trunk bugs.If when a trunk bug is fixed, it was marked with the appropriate fixed and verified keyword, we would always be clear where the bug is fixed and would not have this continuing confusion. Thoughts?
  • this is the way we’ve always done things

  • sometimes (even now) it’s unclear that 1.9.2 will indeed be the next branch
  • people felt like trunk is trunk, and we should be using FIXED and VERIFIED keywords that way
  • QA could also add the verified1.9.2 keyword (or verified-next-milestone-here) in addition to using verified as a way of helping, though