Firefox3/StatusMeetings/2007-11-06

From MozillaWiki
Jump to: navigation, search

« previous week | index | next week »

Firefox 3 Meeting

Meeting Details

  • Tuesdays - Firefox 3 - 11:00am Pacific, 2:00pm Eastern, 19: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 #granparadiso for backchannel

PRD Status Update

Open Action Items

Schedule & Tree Rules

  • beta 1 is now code complete
    • as of 10:50 PST today we're at 0 M9 blockers on front and back end
    • yay!
    • filed bug 402605 to track rename to "Firefox 3 Beta 1"
      • filed bug 401741 to track build and additional version bumping
    • one late string change requires some l10n catchup
      • Axel: should we hold closing the l10n trees to allow them to catch up?
      • agreed to hold l10n builds for 24 hours after go signal for en-US
      • will be closing the tree for M9 shortly after this meeting
  • plan & schedule for Beta 2 and beyond
    • see endgame plan
    • list of Firefox 3 release blockers
    • basil: AMO API needs to be reviewed to ensure it's not going to be a blocker, AMO v3.3 (API) bug list
    • action: anyone with a blocker that requires UI decisions should add "uiwanted" keyword
    • action: add "highrisk" keyword to blockers that you forsee being risky or very time consuming
    • action: make sure to take a look through the unassigned blocker list so that your list of blockers is truly representative

Work in progress

  • Web-based protocol handling (PH team)
  • Download Manager
  • Password Manager (dolske)
  • Add-ons Manager (Rob Strong, Mossop, mwu)
  • Security, Privacy, Identity
    • bug 401575 - SSL Error pages now include inline exception mechanism
  • Installer
  • User Experience
  • Theming/Visual Makeover

Security Review

  • Design Review Proposal
  • Suggested order for review
    • Password Manager (done)
    • Offline Apps ([done])
    • Web Content Handlers (up next)
    • Microformats (mkaply)
    • RSS (sayrer)
    • Add-Ons (rob_strong) (in progress)
    • Places (dietrich)
    • Cross-domain XMLHttpRequest - Done.
    • Distribution/Customization
    • ContentEditable
    • Private Browsing
    • Malware Protection

QA Status/Topics

  • Fx 3 Test Plan wiki
  • Status of FF3 feature verifications to date. (See Feature Tracking tab on Spreadsheet)
  • QA tracking wiki for critical issues opened. Differs from the M9 blocking list.
  • M9 blocker verification status:
    • 10 Core bugs verified
    • 11 Firefox bugs verified
  • M9 release Test Plan
  • Top crashes reported here on 1.9 builds.
  • bclary to run Spider automation against Top sites on windows and linux nightly builds. Detecting asserts and crashes.
    • Repro'd one crash bug from run last week: Bug 379693
  • This week's testday topic is M9 Beta 1. All Firefox 3 devs, please join to #testday on friday to help with questions and focused testing.

Localization Topics

Last l10n-impact change on Monday, 2pm. Check-ins since Friday night

Round table

  • Signup for landing bugs right after M9 freeze ends here (damons)

Gecko 1.9 Meeting

Meeting Details

  • Wednesdays - 11:00am Pacific, 2:00pm Eastern, 19: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)
  • join irc.mozilla.org #granparadiso for backchannel

General Discussion

  • Your top priority should be:
    1. Setting the priority on your blockers with the following proposed criteria:
      • P1 and P2: These bugs are bugs that must be fixed for beta 2; they will get the beta 2 blocking flag once we add that flag. These bugs should be high impact or complexity (see criteria below).
      • P3: These are bugs that are not beta 2 blockers, but are still important blockers with moderate impact and complexity.
      • P4 and P5: These are bugs that we still think should be blockers, but if there are bugs that are going to fall of the list, these are the ones that will get axed.
    2. Triaging your noms down to zero, performing the prioritization in step 1 above, and keeping them as close to zero as possible.
  • Priorities for all blockers must be set by 11:59 PM, Thur, Nov 8, PST. This responsibility falls on bug owners and component owners (?)
  • Discuss Driving Subsequent Releases
  • Current list of beta 2 blockers.
  • Only P1 Blockers

We only have 4 weeks between the beta 1 and beta 2 branch points due to the holiday season.

We have 700 bugs currently marked as blockers. That's too many.

We're asking (requiring) component owners to set priorities on blockers, as a first pass of what bugs should be beta 2 blockers. You want it to be about 10% of blockers, or what you can get done in 4 weeks.

Note that we'll be doing pretty much the same thing for beta 3, which means that something like 80% of the ~700 bugs currently marked as blockers will not be fixed for Firefox 3. The hope is that by "fixing the most important blockers" several times, we'll get to a point where we can cut the rest without feeling bad about the quality of the release. (And if we do feel bad, we can add an extra beta or two.)

After the Firefox3/Beta2CheckinQueue clears, it's likely that bugs will require milestone-specific approval.

Beta 2 criteria, proposal 1

  • Should go in for beta 2:
    • Bugs likely to cause regressions -- it is better to land risky patches for beta 2 than later!
    • Bugs that prevent many users from browsing the web on a daily basis
    • Security issues
    • Top crashers
  • Can go in for beta 2:
    • Memory leaks
    • Performance issues
    • Major regressions from Firefox 2
    • Functionality in support of a P1 PRD item (?)

Beta 2 criteria, proposal 2

Maybe listing all those criteria (like in "proposal 1") isn't especially productive: it leaves out many reasons bugs might be "important" for other reasons. For example, a bug might be important now because it affects Leopard, or because we suddenly realized it is critical for Chinese users, or because web sites are using XHR more than they did when we released Firefox 2. ("Bugs that prevent many users from browsing the web on a daily basis" gives a way out, but why not make that the only criterion?)

  • Should go in for beta 2:
    • The 10% most important blockers
    • Anything risky (likely to cause regressions) among the next 10% most important blockers
  • Should go in for beta 3:
    • The next 10% most important blockers
  • Should be cut from Firefox 3:
    • New features that have not gone in yet.
    • Any patch with too much risk of regressions to go in at the beginning of the beta 2 cycle (because there will never be a safer time to land them)
    • The rest of the "blockers" (80% ?)

"Importance" should be judged largely on how much the bug would "prevent users from browsing the web on a daily basis". This allows bugs to be compared on equal footing whether they are crashes, regressions, Leopard bugs, or even long-standing bugs that we had hoped to fix in Firefox 3. (One major exception to this is security issues.)

Blockers and Noms

Blockers report:

Platform Round Table

  • GFX Update
    • Status of prioritization of Beta 2 P1s and Beta 2 Blockers?
    • 1 P1
    • 6 P2s
    • 14 printing bugs.
  • Layout Update
    • Status of prioritization of Beta 2 P1s and Beta 2 Blockers?
  • Content Update
    • Status of prioritization of Beta 2 P1s and Beta 2 Blockers?
  • Mac OS X Update
    • 20 Blockers remaining.
    • 1/2 are planning to do for M10.
    • Status of prioritization of Beta 2 P1s and Beta 2 Blockers?
  • Build Tools/Toolkit
    • bug 346214 - Vista icon doesn't build on current refplatform. Will require updating MozillaBuild + Platform SDK on Win32 refplatform