[Chandler-dev] [Sum] March 19 - 25

Katie Capps Parlante capps at osafoundation.org
Thu Apr 12 22:34:32 PDT 2007


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


More information about the chandler-dev mailing list