Build, Release and QA --------------------- *Weekly checkpoint* Bear spins: http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007887.html Dan tests: http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007900.html
*Record script* Heikki had comments and questions based on some of John's commits wrt the recorded scripts, in particular related to ForceQuit and Chandler exit. No response to Heikki's comments. http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007885.html http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007886.html *Litmus* Jared gave a link to Litmus, Mozilla's tool for managing test cases in a public way. Heikki and Aparna mentioned that we tried using the precursor (TestRunner). They are both interested in trying out Litmus after Preview. http://litmus.mozilla.org/ http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007888.html *Performance scenarios* Heikki gave an update on the primary scenarios that we're looking at for performance. He also adjusted targets. In particular, we've added two: - Quick entry in dashboard (with 3k calendar) - Triage in dashboard (with 3k calendar) If we hit acceptable values on all platforms for a given scenario, we can move the focus to other scenarios. Heikki moved the primary scenarios to the top of the tinderbox report, and changed the coloring. - Green if we are under the *ideal* time - Orange if we are under the *acceptable* target, but not ideal - Red if we are above acceptable (focus cases for Preview) We are working on getting data sets that are more representative of real users' data given the Preview feature set. http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007926.html Heikki preferred being able to see changes at a glance, vs absolute values. Philippe described a difference between performance monitoring and reaching performance goals. He noted that understanding how far off we are from goals is the important focus right now. Once we have a baseline, we can switch to more of a performance monitoring mode (focused on regressions). http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007927.html Dev --- *Skipping out of the box* Morgen noted that we probably want dump/reload to skip "out-of-the-box" items that get created upon startup. Morgen and Phillip agreed to handle this by not dumping anything under the parcel's tree. http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007903.html Heikki asked about the "dummy" password -- it should be dumped and replace the existing dummy when reloaded. Morgen described how parcels should handle preferences (the dummy password fits the same pattern). The parcel should define a record type containing fields for information the parcel needs to dump/reload. The translator converts the parcel data into records (and vice versa). Morgen gave sample code for the Password record definitions, and more detail about how dump/reload works. http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007905.html *Throttle for Sync?* Morgen asked if we have control over CPU usage of background operations running in a PeriodicTask. PJE responded in the negative (at least not without platform specific thread priority hacks). http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007909.html *Eliminate __init__ methods for Item subclasses* PJE, Morgen, Bear and John proposed doing away with custom __init__ methods for Item sublcasses. This would help dump/reload handle type changes in a safe way (ultimately supporting a faster dump/reload). Scope of changes: - 1/4 of existing methods not doing anything - 1/4 set computed initial attribute values (e.g. createdOn) - 1/2 update global data structures, set up listeners, etc. To replace the functionality, adding 2 schema features: (1) __setup__(self): called when Item is created or when class changes. Used to handle global housekeeping and listener setup. (2) schema.initialValues(): you can call in the body of a class to define how the class' attributes should be initialized (e.g. initialize createdOn). Keyword arguments are used for attribute names, the values are functions taking the item as an argument and returning the desired attribute value. PJE and Morgen can already replace all but two cases and run all but one test successfully with the change. http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007907.html Bryan asked if observers and reindexing could be deferred for attribute initialization. Grant worried this would be dangerous. PJE asked for specific examples where deferring was important. Bryan gave one involving Reminders. Andi, Grant, Bryan and PJE continued to discuss the finer points of filters, monitors, indexes, initial values, and boatloads of bookkeeping. Eventually they moved the conversation to IRC, and agreed to something not clear to this summarizer. http://wiki.osafoundation.org/script/getIrcTranscript.cgi?channel=chandler&date=20070322 http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007925.html *notificationsDeferred* Andi added the third API in the series. He uses it during merging, and while setting initial values passed via keyword args to the top Item __init__() method. notificationsDeferred() takes precedence over the others: it makes sense to nest it as the innermost call when combining with the others. Deferred notifications are applied in the order they were queued. Andi also added cancelDeferredNotifications(), which doesn't reset the deferred mode, it just clears the list. Andi described some complexities with indexing and deferring notifications, he recommended nesting notificationsDeferred() under reindexingDeferred(). http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007931.html *mvcc?* Andi suspects mvcc may play into Bug 8268 (MemoryError) and is also looking at Bug 8463 (100% CPU). He's turned off mvcc by default. He's curious to see if the bugs pop up with mvcc off. http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007932.html Andre explained that without mvcc, sync is less CPU intensive, but longer. He prefers mvcc to be on. http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007935.html Meetings, Announcements ----------------------- Platform team: http://wiki.osafoundation.org/Journal/Platform20070320 IRC QA session: desktop triage http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007895.html Dev meeting: http://wiki.osafoundation.org/Journal/EngineeringMeetingNotes20070322 EIM and Edit/Update coordination meeting notes: http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007929.html Discussion of TalkShoe vs Skype starts here: http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007934.html _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
