[Chandler-dev] [Sum] Feb 26 - March 4
Katie Capps Parlante
capps at osafoundation.org
Wed Apr 11 15:29:45 PDT 2007
Build, Release and QA
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).
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
*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
Phillip requested a target that does *not* remove release.
QA and dogfood
When Cosmo 0.6 went up on osaf.us, Andre had troubles restoring his
collections. Thread starts here:
Morgen, Randy, Jared and Jeffrey tracked this down to two problems:
(1) an iCalendar related bug surfaced by events imported from Plone
(2) paths with "/cosmo/home/" not working properly ("/cosmo/dav/" works)
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.
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
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
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.
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
*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
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
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.
(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
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
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.
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
- 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
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.
Morgen explained that "Test > Sharing > Edit your name" will edit the
last name on the "Me" contact item.
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.
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.
QA IRC session testing email:
Cosmo 0.6 release, available on osaf.us:
More information about the chandler-dev