Build, Release and QA --------------------- *Weekly checkpoint* Bear spins: http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007780.html Dan tests: http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007786.html
*Performance* Heikki did performance tests with real world data (Katie's data), and compared that to the 3000 event calendar that we use in our performance metrics. Differences in the real-world data set include multiple calendars with many events, most events are recurring events, and many events are shared between collections. - 6/11 cases were notably slower with real world data - 3/11 cases were notably slower with the test data Heikki asked for other data sets to test with (send .ini file). http://wiki.osafoundation.org/Journal/PerfDataComparisons20070227 http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007783.html Bryan Stearns had a few ideas for performance improvements as he was working on other tasks. He asked for comments. - Rearrange ContentItem class chain for performance - For perf, don't use an observer to set triageStatusChanged http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007806.html *Clean, distclean, realclean* Heikki's proposed changing the chain of clean: - distclean: removes release or debug, and eggs/plugins - clean: distclean, followed by remove *.py[co] - realclean: clean, followed by removing release AND debug, followed by removing tarballs Phillip requested a target that does *not* remove release. http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007817.html QA and dogfood -------------- *Migration woes* When Cosmo 0.6 went up on osaf.us, Andre had troubles restoring his collections. Thread starts here: http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007787.html Morgen, Randy, Jared and Jeffrey tracked this down to two problems: (1) an iCalendar related bug surfaced by events imported from Plone http://lists.osafoundation.org/pipermail/cosmo-dev/2007-March/003077.html (2) paths with "/cosmo/home/" not working properly ("/cosmo/dav/" works) http://lists.osafoundation.org/pipermail/cosmo-dev/2007-February/002985.html Update: at the end of the day we were unable to completely fix this problem, so changing urls (e.g. in restore .ini files) is recommended. http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007796.html *Memory Error* Andre runs into "MemoryError" traces and a variety of other problems after leaving Chandler running overnight. He and Andi discussed the problem (as yet unresolved), which is being tracked in Bug 8268. Thread starts here: http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007802.html *Safe stamping* Andre asked if one could stamp an instance of a recurring event as a task. He gave a scenario: birthdays as yearly recurring events with alarms -- put an upcoming instance in a new collection and stamp it as a task. http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007798.html Jeffrey noted that stamping works ok, but unstamping again has some problems with the soon-to-be-obsolete sharing code. He also observed that individual occurrences can't live in different collections for Preview. http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007799.html Grant mentioned Bug 7446: a problem with the recurrence dialog and unstamping. Grant confirmed that the dust has not settled on recurring events: we're still looking at significant changes, mainly to improve performance. http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007815.html Dev --- *Dump et Reload? Backup et Restore?* Bear asked if we could use the term "Backup and Restore" for a complete backup of Chandler data that is cross-platform and schema-version independent. http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007773.html Andi explained a problem with this proposal: the current "Dump and Reload" is incomplete, and "Backup and Restore" is not cross-platform or schema-version independent. The current "Dump and Reload" targets user-data for migration across versions. The current "Backup and Restore" makes a complete backup of the repository. Andi agreed the names are confusing, offering a few options. - Conflate the two (hardest) - Rename "Dump and Reload" to "Migrate User Data" - Rename "Backup and Restore" to "Repository Copy" or "Repository Duplicate" - Make it clear in docs and UI that "Backup and Restore" does *not* support schema or format migration http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007779.html *Recurrence merging* Jeffrey described a merge problem when restoring two different collections with multiple versions of the same recurring event. In parallel, two threads separately create occurrences for the same master event, and hilarity ensues when putting the pieces back together again. Possible solutions: (1) restore collections in sequence, not in parallel (2) make occurrence UUIDs be derived from master UUIDs, so that the repository can recognize the occurrences on the different threads as being the same events http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007774.html Morgen and Grant pointed out other cases: - background sync happening at same time as subscribe - user changes an item at same time as background sync http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007777.html The complexity of guarding against the other cases led Jeffrey to propose that we work through the problem, instead of trying to avoid parallel restores. He observed that "restore" functions as a good bug finding tool for more rare conflict cases. http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007778.html *Bi-line* A design list conversation about bi-lines wandered in to chandler-dev. Grant mentioned that lastModifiedBy hasn't been implemented yet. Morgen explained that the sharing layer is currently assuming lastModifiedBy is a bi-ref to an EmailAddress item. Morgen wondered about the 3 scenarios he understood: - email address - sharing account - no accounts set up (subscribing via ticket) Morgen is hoping we can consistently use an email address until we have a Contacts implementation. Alternatively, we could model it as a string attribute. http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007808.html Mimi asked about adding an email address into the sharing account form. We require one for signing up for an account directly via the web. Morgen agreed that is one option, but doesn't take care of the no-account situation. Morgen is in favor of going with the string option, which gives us flexibility. The user could be prompted for the string at startup, or be able to edit via a menu item. Under the hood we could track this as a Contact item. http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007814.html Morgen explained that "Test > Sharing > Edit your name" will edit the last name on the "Me" contact item. http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007824.html *Re-indexing* Bryan and Grant requested support for being able to set multiple attributes on an item "at the same time", so that observers, monitors and index changes all happened once after the change. Andi took a shot at the goal by adding a reindexingDeffered() feature. (He gave sample code in the message). This feature required some rework to monitors. He asked for comments, and if "observersDeferred" should be next. http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007823.html PJE liked the feature. He noted that he'd like to see a single block operator that defers all side effects, notifications, etc. and rolls back changes if errors occur. He acknowledged it might be tricky to get this right in practice, so perhaps not a near future goal. http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007825.html Meetings, Announcements ----------------------- QA IRC session testing email: http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007782.html Cosmo 0.6 release, available on osaf.us: http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007788.html Apps team: http://wiki.osafoundation.org/Journal/AppsMeeting20070301 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
