Mozilla 2/StatusMeetings/2008-04-02

« previous week | index | next week »

Mozilla 2 Meeting Details

• Wednesdays - 11:00am Pacific, 2:00pm Eastern, 18:00 UTC
• Mozilla Building S - <script> conference room
• 650-903-0800 or 650-215-1282 x91 Conf# 217 (US/INTL)
• 1-800-707-2533 (pin 369) Conf# 217 (US)
• irc.mozilla.org #mmgc for backchannel

Status Reports

• jimb
  • autoconf+spidermonkey -- ready for review?
• dmandelin
• taras
  • Various improvements to de+treehydra
  • Working on gcc summit paper
• bsmedberg
  • XPCOMGC is slow work: keep running into tooling issues such as MCPP bugs and dehydra bugs; each one is not hard to fix, but all together it makes things really slow!
  • Wrote up Mozilla 2/Memory work item (OOM and GC support for jemalloc)
• shebs
  • dehydra fully functional on OS X (thanks Vlad Sukhoy!), need to package for general use
  • looking at how to hook into other C dialects

Discussion

• opening mozilla-central for general checkins is tracking bug 422754

• Need to finish Mozilla_2/Work_List
  • Centralized security checks - brendan
  • Protected mode - jmathies/rstrong
  • GFX - 3D Acceleration - vlad

• FF.next, FF4 plans, how it affects moz2 (schrep)

Meeting Notes

Opening mozilla-central. Items tracked by bug 422754. bsmedberg to write up tree rules.

Basic tree rules as proposed on the newsgroups. No regressions, period. We've learned our lesson from 1.9; landing something to get integration testing while it has known issues is unworkable.

Discussion: does that mean zero regressions, or just zero regressions in the automated tests? dbaron and others agree: no known regressions at time of landing. Regressions found later are need to be fixed immediately or backed out. Backing out should be the answer of first recourse.

Schrep introduced the question of FF.next plans and how it affects moz2 and mozilla-central:

• We have features and fixes which are mostly ready now, but we can't delay the 1.9 schedule for them:
  • video
  • XHR
  • futher JS perf improvements
• For product reasons, we'd like to be able to push these sooner than next year.
• a release of Firefox.Next in Q4 2008
  • The scope should be limited to well-known features: reduce risk wherever possible
  • Proposed solution: cherry-pick relevant changes from mozilla-central onto a 1.9.1 branch
• recognize concerns about splitting the testing and development community
  • mozilla-central builds should be the default for nightly testers
  • development should focus on mozilla-central, with backporting

Stuart disagrees: we should go through with a plan to do "mozilla 2" which means only the ability to break APIs. That's mozilla-central: it should remain stable and we should pick a point and do a release from there.

Long and wandering discussion about the value of frozen APIs versus not-breaking plugins or binary extensions... I'm sorry the notes aren't more clear here. General agreement that we shouldn't go changing APIs without a good reason to do so. General misunderstanding about whether we're only discussing @status FROZEN APIs, or all APIs:

• on 1.8/1.8.1, we promised not to change any interface
  • we broke that promise once (changing nsIDocument IIRC)
• stuart argues: our frozen APIs are holding back development
• schrep: can you give specific examples that we would need/want to change before the proposed 1.9.1? ... not offhand
• bsmedberg: I understand stuart's concern: we don't want to repeat the 1.9 cycle with low testing coverage and massive divergence. What about if we start using mozilla-central, and at that point we need to make a change which is too risky for 1.9.1, then we branch? But avoid branching until necessary.
• brendan: the problem is not necessarily breaking APIs, but latent bugs which aren't discovered. We'd like to reduce risk for 1.9.1 but cherry-picking very selectively
• discussion about the limitations of automated testing and how many bugs are only picked up in the wild: even at beta5 we're only now learning of some important web-compat bugs

At the meeting conclusion, there was not total agreement. However, the following decisions were made:

• It's important to get mozilla-central up and running ASAP
• For now, we will try to do FF.next development from mozilla-central
• We will not make breaking changes to @status FROZEN APIs without making a more solid decision about 1.9.1 and perhaps branching