Firefox 3/Gecko 1.9 Meeting Details
- Tuesdays - Firefox 3 - 11:00am Pacific, 2:00pm Eastern, 19:00 UTC
- Mozilla Building S - Central Area
- 650-903-0800 or 650-215-1282 x91 Conf# 217 (US/INTL)
- 1-800-707-2533 (pin 369) Conf# 217 (US)
- irc.mozilla.org #granparadiso for backchannel
Open Action Items
Schedule & Tree Rules
- current checkin rules
- triage will continue over the holidays, but approvals will be slower than normal
- discuss priorities on blockers (schrep)
- looking to code freeze for b3 around Jan 22nd
Gecko Blockers and Noms charts:
- Stacked Blockers
- Stacked Noms
Priority Level charts:
Work in progress
- Beta 3: 99 blockers (P1:4, P2:26, P3:50)
- Design Review Proposal
- Still needed
- Microformats (mkaply)
- Malware Protection (dcamp)
- Distribution/Customization (thunder)
- Completed beta 2 RC testing with Results. There were a lot of issues found, but nothing blocking.
- only live updates and website/relnote checks remain.
- Marcia ran a tab switching test against beta 2 trunk and branch. Things to highlight:
- Tests ran on trunk on 12/14 were almost 3000 ms faster than reported on 10/10
- However tests on branch ran on 12/14 were twice as slow than reported on 10/10
- Further testing is needed. There were many variables in the environments (apps open, slower memory), so next step is to create a more uniform test environment. Long term: this should be automated.
- Tomcat ran a memory leak run against trunk on XP. 5 new leaks were introduced, and being investigated.
- Tracking in Bug 402335 (the last 5 issues are found over weekend):
- He'll be running a mac debug build next week.
- Another successful b2 testday last friday running over 500 testcases by community members. Testday Summary here.
- Testday this week is on Trunk builds. Last one of the year. Please join #testday on irc, friday, between 7am - 5pm PST.
mozStorage Database Corruption/Functionality Issues (bug 402615)
I'll try to include as much as possible here since I won't be on call. We've been seeing more and more database corruption/functionality bugs. bug 402615 has some bugs depending on it that are these corruption instances. I've seen at least one other bug go by that I don't have time to search for. These issues are real, and I suspect we'll be getting lots of more them once we start getting more users using our product. It is my belief that this issues would be better identified by removing the async IO that we do on a worker thread.
These issues have a common situation where once something starts to fail, everything is (because async IO got an error at some point, anything it does after that point will fail). If we get rid of this, the original call (like mozStorageConnection::ExecuteStep & friends) would be the one that fails, and the caller has an opportunity to recover.
There is, of course, a down side to removing our async IO. It was added in bug 326334 to help perf. I have not done any tests to see if this is still relevant (vlad would probably be the person to ask for more details on this). If someone wants to see if this is still a serious issue with our perf numbers, there are three lines of code that can be commented out that will disable async IO (this is untested, so I don't know if it compiles):
On a side note, if we get rid of async IO, I suspect it would be fairly trivial to upgrade to the latest version of SQLite (3.5.4 - we are running 3.4.1). 3.5 provides us with concurrent reads and writes with the shared cache, which we can't do now (requires adding some threadsafety to mozStorageConnection & friends, but that's not terribly difficult). Having concurrent access on db connections means that we can fix perf hot-spots by having that bit of code write to the DB on a worker thread.