Calendar:Status Meetings:2007-10-17

From MozillaWiki
Jump to: navigation, search

<< previous meeting | index | next meeting >>

Meeting Details

Telephone Info

  • Toll free numbers
    • US/Canada: 866-692-3163
    • Netherlands: 0800-020-1392
    • Germany: 0800-000-3441
  • Participant Passcode
    • 3182189
  • Conference controls
    • Press *1 private help menu
    • Press *6 mute or un-mute individual line
  • Each time you say something, please say your name first so people know who's speaking

Agenda Items

  • 0.7 RC2 Status for tomorrow's test day
    • l10n status
  • Preparing 0.8/0.9: I'd like to hear more opinions on tracking the next release.
  • David Ascher asked us for TB 3 requirements. We should start to collect those.
  • Should we overcome "vanilla lightning/sunbird ships only with ics/caldav support"?
    • Should we ship with all providers hosted in mozilla-cvs?

Meeting Log

  • Attendees: mickey, mschroeder, sipaq, daniel
  • 0.7 RC2 has been packaged and uploaded by ause, sipaq is going to announce RC2 and point to tomorrow's test day.
  • We will remove monogolian locale mn from shipped-locales; nobody has worked on it since 0.5.
  • There has been a consensus to integrate more providers into future release packages, foremost gdata. Every added provider puts more burden on release drivers, thus we'd like to define some requirements, e.g.
    • A provider needs to satisfy a reasonable user demand (e.g. votes).
    • A provider needs to have a clear module owner who keeps track of maintenance work. If there is no such person, release drivers could decide to drop that provider from the release.
  • David Ascher asked for requirements w.r.t TB3:
  • The next release will be 0.8, granting us the possibility of another release (0.9) before 1.0.
  • We discussed how to improve release tracking:
    • Providing a rough estimation to bug readers when a feature/fix is to be expected, we will use the target milestone field, especially w.r.t. roadmap items.
    • Tracking the next release (0.8), we will use
      • A wanted flag to cover what the release drivers want to focus on for a release.
      • A blocking flag towards the end of a release cycle, getting a stricter focus on what really blocks a release.
    • It's still open whether we will use versioned wanted/blocking-flags, e.g. "wanted-0.8" or use a constant one, e.g. "wanted-next-release".
    • Release drivers need to reevaluate what's wanted again for every release: wanted+ bugs that have missed a release shouldn't automatically get wanted+ for the next release.