Platform/2010-08-10
« previous week | index | next week »
Contents
Announcements
- Firefox 3.6.4 post-mortem is this Thursday, 2010-08-12 @ 11:00 am PST. More information is here.
- Continue to focus on blockers.
Tree Health
Three things must improve:
1) Mistakes must be less costly. This means faster build machines, faster infrastructure. We're making progress here.
2) We must make fewer mistakes on shared infrastructure. Totally unacceptable: checking in and failing every build or leaking on every test, on every platform. This goes for TryServer as well: it is not your compiler. Be respectful of other people's time.
3) Check to see if the tree is orange before checking in. Sheriffs are going to start backing people out for doing this because it's rude and may end up closing the tree because orange got landed on top of orange. When in doubt, ask the sheriff.
Additionally, we're looking at separating some work onto separate repos, with the same rules as mozilla-central, in order to reduce traffic on mozilla-central.
Feedback here mozilla.dev.platform thread.
Notices / Schedule
Firefox 4 Beta
- Beta 3 should hit QA signoff later today, will release tomorrow
- QA's beta 3 bugs for those interested
- Beta 4 code freeze scheduled for next Monday
- would like all major landings to be complete by this Friday, though (see Roundtable)
- feature freeze still scheduled for Beta 5
- a "feature" is any code which creates a new or makes a significant change to existing interactions between the user and the browser, developers and browser APIs, or web authors and the browser
- after feature freeze we will only be stabilizing and polishing
Firefox mobile (alpha)
- CODE FREEZE IS TODAY
- Bug list
Blocker Report
Firefox 3.6.9
- There are 26 open blockers (+4 w/w)
- Code freeze is currently scheduled for Thursday August 12 @ 11:59 pm PST
- Let's try to not get them all in on the last day. I'll be bugging people furiously this week and the start of next
- Only approving blockers at this point
Firefox 3.5.12
- There are 16 open blockers (+3 w/w)
- Code freeze is tied to 3.6.9
Firefox 4 Beta
- a handy list of triage queries is available for all!
- Beta 4: 56 blockers
- Beta N: 218 blockers
- Final: 232 blockers (559 total)
- nominations: 275 nominations (153 OPEN)
Firefox Development
(from our goals):
- [ON TRACK] Feature complete Firefox 4
- [DONE] Switch to Tab
- [DONE] App Tabs - Scope for 4.0 reduced (non-global), near feature complete.
- [DONE] Extension Manager - Bug list is converging, still a lot of work to do.
- [DONE] Web Console
- [ON TRACK] Notification UI - Geo and EM notifications done, http auth next.
- [ON TRACK] New Theme - Windows and Mac good, Linux catching up now
- [DONE]
TabCandyPanorama - [AT RISK] Silent updates on Windows
- [DROPPED] Inspector
- [DROPPED] Account Manager - WIP patches posted, but we can't contain the review load and code risk.
- [AT RISK] Dirty profile startup within 20% of clean profile startup (modulo extensions, plugins; on windows)
- Current status: Lots of data has been collected and analyzed, but no solid conclusions have shaken out.
- Details page
- Shawn has an updated blog post. Read it for more info.
- Bugs on file that help:
-
Excessive cookie i/o bug bug 572223(fixed) - Session Restore negatively impacts startup time based on the number of tabs loaded bug 582005
-
Suboptimal SQLite page size bug 416330(fixed) - Provide a global VACUUM component bug 541373
-
Platform
(there is a team-by-team goals breakdown, as well)
- [DONE] Javascript performance near or even with Chrome 5 on their benchmarks (within 20% on SS, 30% on V8), with substantial wins on our benchmarks. (Windows, in-browser.)
- [DONE] Hardware acceleration of video and other HTML and SVG content, as well as user interface, on by default for compatible hardware on all Tier-1 desktop and mobile platforms.
- [DONE] Fully support the WebGL 1.0 spec, with support turned on by default in a Firefox 4 beta on platforms that support OpenGL or OpenGL ES.
- [MISSED] security: zero reproducible high/crit > 30 days
- [DONE] Support multi-process Fennec.
- [DONE] Support Jetpacks running in separate processes and never blocking the Fennec UI. NOTE: jetpack team hasn't actually integrated this code yet, but it works in small test environments.
Layout
- bzbarsky has implemented JS animation API that can keep in sync with transitions/SMIL etc
- Very simple, should land shortly
- bug 130078 making progress, many parts landed
- We're not testing retained layers very well on tinderbox machines: screen sizes mean our windows are too small to display entire reftest, so reftests don't grab data from the retained layers
Video
- Landed 'buffered' support for Ogg/WAV
- Patch in hand for basic WebM 'buffered' support, will follow up with optimizations
- Will set up a test machine to compare Flash with our video under controlled conditions
JS
- JM conformance and perf continues to improve
- YARR regex lands this week on TM and MC
- ES5
- No landings this week, but now awaiting review on bug 514581, bug 514563, bug 584909, bug 585803, bug 438633 and very nearly bug 516255
- Current work
- Requiring exact argument count for getters/setters in bug 536472
- Poison-pill for fun.caller and for arguments.caller and arguments.callee
- Make arguments[i a copy of that initial parameter, not a reflection]
- JSON stringification bugfixes
- Killing an extra warning for duplicated property names
Windows 7 Test Status
Tree Management
- Tinderbox woes
- Read Ben's blog for current status and plans to make things better.
- Rebalancing pool size - moving some machines from production to try
- 10.6 builder upgrades in progress - should be unblocking buildsymbols today/tmrw
Roundtable
- <sayrer> Meeting starts at 11:00 PT. Be here on time.
- <beltzner> New milestone code freeze process
- For Beta 3 we tried to land Firefox Sync. We failed to check assumptions about previous performance and unit testing, which left us in a bad state on Monday and eventually slipped the code freeze. Lots of things learned about tryserver (which can and should be used to pre-evaluate large landings!) and the implications of committing early to a feature in a specific beta in the ensuing investigation.
- TraceMonkey merge caused some functional regressions that required respins and delayed beta ship - hard to see due to intermittent test failures and number of landings
- We need to have a solid tree the weekend before a planned code freeze, with any major landings having been tested for performance and functionality before Friday and landing by Friday end of day. Anyone who lands after Friday *must* stay around to ensure there are no performance or test regressions in their code.
- Suggested new process
- Code stabilization on Friday, end of day PT
- No new strings between stabilization and freeze
- Only bugfixes between stabilization and freeze
- Everyone must monitor full tests after checkin between stabilization and freeze
- Freeze Monday midday PT following code stabilization
- this process was generally agreed-upon at the meeting
- <blizzard> UA changes - get them done now
- dwitte to file a blocking bug and drive the process through bug 586165
- <bsmedberg> wants to discuss the following blocker nominations
- resource packages bug 529208: no cross-browser spec, concern about whether it will actually improve perf, questions about whether it will be deployed with a moz Prefix or not, and little or no reviewer time to actually take it
- performance improvements in plone show up to 25% page load improvement (jonas)
- feels like we should be making a push to take this one, and it would be a bummer if we couldn't get it (sayrer)
- no decisions made about how to resource it
- desktop omnijar bug 556644: the current plan involves repacking locale files, which is going to require lots of testing and regressions may show up late. I'm very concerned and if it is a blocker we need better ways to mitigate risk.
- very valuable win on startup time (shaver)
- felt that this needs to be a blocker, people need to file blockers on the follow-up issues
- resource packages bug 529208: no cross-browser spec, concern about whether it will actually improve perf, questions about whether it will be deployed with a moz Prefix or not, and little or no reviewer time to actually take it
- <beltzner> Using Tryserver
- investigation from Sync showed that Tryserver successfully predicted test failures and may have predicted Talos regressions - it's just that nobody looked
- tryserver now faster (though wait time on Windows can still be high)
- uses same test infrastructure as mozilla-central
- releng very interested to hear why developers aren't using it, how they can help
- joduinn to schedule follow up meeting
- in the meantime, you can always leave a suggestion about what could make it easier for you to use the infrastructure
- <stuart> Getting Reviews
- It is taking an awful long time to get initial reviews for many blocking fennec bugs. Are people not looking at them, or using bad queries?