[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
---------------------
*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



More information about the chandler-dev mailing list