Discussion on ItemCollections^? work

• Won't hold milestone M4 for this work
• Attempt to get it in before the feature complete date because there are dependencies
• Some discussion of possibilities for branching

Plans for 0.5.M4

• Some applications work may stretch the time available..
• Sheila plans to review bugs targeted to M5 to see that we've got the remaining work covered
• Schema API work already in, done
• PyICU^? work is mostly wrapped
• Technical specs like recurrence and i18n are in good shape but those features aren't showing up until M5.
• Sharing stuff: expected to be complete except for possibly 1 task.
• We need to make sure we haven't scheduled much more than one month of work for M5 simply by pushing stuff back from M4 or by not understanding the work well enough.
• We asked ourselves if we need to push out M4 to do more of the ItemCollection^? and recurrence work and all of the planned sharing work, but we'd rather do M4 now at the possible risk of adding another milestone at the end of 0.6. One reason to do M4 next week even with the slips we've got is that we want to take a snapshot for OSCon.

Long-running Chandler

• Andi's working on this
• Not sure what the requirements are for 0.6 -- a couple days to a week?

0.6 Expectations

• Who is going to be using our "usable calendar"? Only internal OSAF people are likely to -- there will still be usability barriers (performance, incomplete QA) that will be serious impediments to people who aren't dedicated to using Chandler.
• Is it going to be a QA'ed release, a consumer-quality release, even of calendar functionality? No. We don't have the QA resources to really know what the bugs are without serious volunteer testing and usage and feedback from users. Compare to how long Mozilla had a serious user base long before it went to 1.0. Or a better comparison, how long did it take Evolution to go from a mostly feature-complete product to a reasonably bug-free product? (Mitchell said they don't consider a Mozilla release to be tested until they have 70,000 downloads)
• Remember we're using import/export rather than doing data upgrade in place. Will we expect users to back up their data manually on a daily basis using export?
• Our 0.6 version of the virtuality will be a challenge to new users to find "usable" although if they only use the calendar features this probably won't be a factor.
• wxWidgets bugs are going to be annoying to many kinds of people
• We won't have interoperability with many servers (IMAP, WebDAV) or with all iCalendar importers/exporters

Conclusion: we'll need really good release notes which Sheila already knows...

Dogfooding plans

• What are the things which block dogfood in M4?
  • No recurrence, timezones, GUI problems?
• What are the things which block dogfood in M5 (feature complete)?
  • Bugs
• Who starts dogfooding and when?
  • Lisa and Ted will start early
  • After feature complete, start encouraging all developers to start dogfooding
  • Pay attention to a good stable point when we can have Esther start to dogfood the office calendar

• If we encounter dogfooding problems after we've started work on 0.7 (after we've "shipped" 0.6), do we shift our focus back to 0.6? Do we continue working on the 0.6 branch? Certainly it will depend on the type of fix -- a big refactoring just might not be feasible to fix in a released build and also in 0.7. But what about a "thousand cuts" of tiny fixes that seem needed for dogfoodability if these continue being found past the end of October and into November?

• Our decison making here might be different if we were really shipping 1.0 -- we'd go back and patch 1.0 so that users could make minor upgrades, we would maintain two code trees long term. But we don't see this as a great idea for 0.6.