Calendar:Status Meetings:2007-10-17
From MozillaWiki
<< previous meeting | index | next meeting >>
Meeting Details
- Wednesday, October 17th, 16:00 UTC
- Phone meeting
- Join #calendar-mtg on irc.mozilla.org for attendance
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:
- chris-j keeps care of possible UI issues.
- mschroeder mentioned ftp issue: see bug 273476 and this discussion
- 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.