Platform/2009-05-05: Difference between revisions
< Platform
Jump to navigation
Jump to search
Samuelsidler (talk | contribs) |
m (→Roundtable) |
||
| (28 intermediate revisions by 11 users not shown) | |||
| Line 2: | Line 2: | ||
=== Notices / Schedule === | === Notices / Schedule === | ||
'''[[Releases/Firefox 3.0.11 | Firefox 3.0.11]]''' | |||
** code freeze tomorrow at 11:59pm | ** code freeze tomorrow at 11:59pm | ||
** only a few blockers left though | ** only a few blockers left though | ||
'''[[Releases/Firefox_3.5b4|Firefox 3.5 Beta 4]]''' | |||
* released last week | |||
* contains lots of great stuff | |||
* well received so far! | |||
'''[[Releases/Firefox_3.5rc1|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 === | === Blocker Report === | ||
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20flag%3Ablocking-firefox3.5%3F%2Cblocking1.9.1%3F 30 blocker nominations] | |||
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=flag%3Ablocking-firefox3.5%2B%2Cblocking1.9.1%2B 86 blockers left without a fix] | |||
'''Since 1.9.1 branch ...''' | |||
https://people.mozilla.com/~beltzner/images/2009-05-05-blocker-report.png | |||
'''Past 2 weeks ...''' | |||
https://people.mozilla.com/~beltzner/images/2009-05-05-blocker-report-detail.png | |||
[ [[Platform/1.9.1|Platform Blocker Queries]] | [http://people.mozilla.org/~beltzner/triage.html Front End Blocker Queries] ] | |||
'''Summary''' | |||
* slow week due to all hands | |||
* need to keep pressure and pace up! | |||
'''The Breakdown''' | |||
* [https://bugzilla.mozilla.org/buglist.cgi?keywords_type=anywords&keywords=fixed1.9.1+verified1.9.1&resolution=FIXED&chfieldfrom=2009-04-28&chfieldto=Now&chfield=keywords&chfieldvalue=fixed1.9.1&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=blocking1.9.1%2B&field0-0-1=flagtypes.name&type0-0-1=equals&value0-0-1=blocking-firefox3.5%2B 6 blockers marked fixed1.9.1 over last week] | |||
* [https://bugzilla.mozilla.org/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=blocking1.9.1%3F&field0-0-1=flagtypes.name&type0-0-1=equals&value0-0-1=blocking-firefox3.5%3F&field0-1-0=flagtypes.name&type0-1-0=changedafter&value0-1-0=2009-04-28 21 bugs nominated for blocking over last week] | |||
** blocking-firefox3.5+: [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&field0-0-0=flagtypes.name&type0-0-0=changedto&value0-0-0=blocking-firefox3.5%2B&field0-1-0=flagtypes.name&type0-1-0=changedafter&value0-1-0=2009-04-28 7 new unresolved], [https://bugzilla.mozilla.org/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&chfieldto=Now&field0-0-0=flagtypes.name&type0-0-0=changedto&value0-0-0=blocking-firefox3.5%2B&field0-1-0=flagtypes.name&type0-1-0=changedafter&value0-1-0=2009-04-28 2 new resolved blocking-firefox3.5+ added] | |||
** blocking1.9.1+: [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&field0-0-0=flagtypes.name&type0-0-0=changedto&value0-0-0=blocking1.9.1%2B&field0-1-0=flagtypes.name&type0-1-0=changedafter&value0-1-0=2009-04-28 12 new unresolved], [https://bugzilla.mozilla.org/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&chfieldto=Now&field0-0-0=flagtypes.name&type0-0-0=changedto&value0-0-0=blocking1.9.1%2B&field0-1-0=flagtypes.name&type0-1-0=changedafter&value0-1-0=2009-04-28 7 new resolved blocking1.9.1+ added] | |||
* [https://bugzilla.mozilla.org/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=changedto&value0-0-0=approval1.9.1%2B&field0-1-0=flagtypes.name&type0-1-0=changedafter&value0-1-0=2009-04-28 14 patches approved for 1.9.1 over last week] | |||
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=FIX%20-!fixed1.9.1%2Cverified1.9.1%20flag%3Ablocking1.9.1%2B,blocking-firefox3.5%2B 77 blockers are FIXED but not yet landed on 1.9.1] | |||
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&keywords_type=nowords&keywords=fixed1.9.1%20verified1.9.1&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=approval1.9.1%2B 38 bugs with approval1.9.1+ that are not yet landed on 1.9.1] | |||
=== Browser / Front End === | === Browser / Front End === | ||
* Blockers: [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Firefox&product=Toolkit&keywords_type=nowords&keywords=fixed1.9.1+verified1.9.1&resolution=---&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=blocking1.9.1%2B&field0-0-1=flagtypes.name&type0-0-1=equals&value0-0-1=blocking-firefox3.5%2B&field0-1-0=resolution&type0-1-0=noop&value0-1-0=INVALID+WONTFIX+WORKSFORME+INCOMPLETE+MOVED+EXPIRED 11 remaining] & [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Firefox&product=Toolkit&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=blocking1.9.1%3F&field0-0-1=flagtypes.name&type0-0-1=equals&value0-0-1=blocking-firefox3.5%3F 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) | * Polish update: Firefox is 55% shiny (+2% over two weeks ago) | ||
| Line 14: | Line 51: | ||
** 44 remaining [http://tinyurl.com/8qnba2 easy polish bugs] (whiteboard [polish-easy]) | ** 44 remaining [http://tinyurl.com/8qnba2 easy polish bugs] (whiteboard [polish-easy]) | ||
** 38 remaining [http://tinyurl.com/9zq9xz hard polish bugs](whiteboard [polish-hard]) | ** 38 remaining [http://tinyurl.com/9zq9xz hard polish bugs](whiteboard [polish-hard]) | ||
https://spreadsheets.google.com/pub?key=pMZGKUlD9NOPg4oJGs1CUMw&oid=1&output=image&foo=.png | |||
=== GFX 1.9.1 Update === | === 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 === | === Layout Update === | ||
| Line 33: | Line 73: | ||
=== JS 1.9.1 === | === JS 1.9.1 === | ||
23 blockers, around 4 with patches in hand. 5 noms. | |||
=== General 1.9.1 === | === General 1.9.1 === | ||
These are bugs that fall outside of components covered by the Gfx, Content, Layout and JS groups: | |||
* [http://is.gd/pSlv 3 blockers] | |||
* [http://is.gd/pSn6 1 untriaged nominations] | |||
=== Mobile 1.9.1 Update === | === Mobile 1.9.1 Update === | ||
| Line 47: | Line 93: | ||
* Initial focus will be responsiveness/stability, ''not'' security sandboxing | * 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. | * 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). | * 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 ([pkasting] As a Chromium contributor I can tell you authoritatively that this is untrue; we don't use or enable RTTI/exceptions anywhere in the codebase.) | |||
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 === | === Tree Management === | ||
* Fixed intermittent orange on talos, Tshutdown tests enabled in talos last week, [http://alice.nodelman.net/blog/post/tshutdown-goes-live/ details here] | |||
* [http://oduinn.com/2009/05/01/infrastructure-load-for-apr-2009/ 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 === | === Roundtable === | ||
* If you worked on a user facing feature, please make sure it is on [[Evangelism/Firefox3.5#User_Experience|this list]] (which will be used to generate the press reviewer's guide, mozilla.com content, etc): | |||
* Blog funnel starting up: [[Evangelism/Firefox3.5/35Days]] - will ask for help/writing | |||
Latest revision as of 18:29, 26 May 2009
« previous week | index | next week »
Notices / Schedule
- code freeze tomorrow at 11:59pm
- only a few blockers left though
- released last week
- contains lots of great stuff
- well received so far!
- 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
- 6 blockers marked fixed1.9.1 over last week
- 21 bugs nominated for blocking over last week
- blocking-firefox3.5+: 7 new unresolved, 2 new resolved blocking-firefox3.5+ added
- blocking1.9.1+: 12 new unresolved, 7 new resolved blocking1.9.1+ added
- 14 patches approved for 1.9.1 over last week
- 77 blockers are FIXED but not yet landed on 1.9.1
- 38 bugs with approval1.9.1+ that are not yet landed on 1.9.1
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)
- Thanks go to: marco, dao
- 44 remaining easy polish bugs (whiteboard [polish-easy])
- 38 remaining hard polish bugs(whiteboard [polish-hard])
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 ([pkasting] As a Chromium contributor I can tell you authoritatively that this is untrue; we don't use or enable RTTI/exceptions anywhere in the codebase.)
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
- If you worked on a user facing feature, please make sure it is on this list (which will be used to generate the press reviewer's guide, mozilla.com content, etc):
- Blog funnel starting up: Evangelism/Firefox3.5/35Days - will ask for help/writing