Platform/2010-08-10
« previous week | index | next week »
Announcements
- Continue to focus on blockers.
Tree Health
Two 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.
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
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.
Windows 7 Test Status
Tree Management
Roundtable
- [jrmuizel] What does "Feature freeze" really mean?
- Graphics is working hard on hardware acceleration, but most of the code is already in the tree. Turning it on is a matter of flipping a pref, not landing a pile of code.
- [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.
- We also took a late TraceMonkey merge for some security issues, which ended up causing some functional regressions that required respins and delayed beta ship.
- 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
- [Beltzner] Making good use of Tryserver
- investigation from Sync showed that Tryserver successfully predicted test failures and may have predicted Talos regressions - nobody looked
- do developers know where to look?
- when do you use tryserver?