Platform/2008-12-16
From MozillaWiki
< Platform
« previous week | index | next week »
Contents
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
- 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
- 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
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