[Chandler-dev] [Sum] March 5 - 11

Katie Capps Parlante capps at osafoundation.org
Wed Apr 11 17:32:04 PDT 2007


Build, Release and QA
---------------------
*Weekly checkpoint*
Bear spins:
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007827.html
Dan tests:
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007840.html

*Logging SSL exchanges*
Heikki points out that network sniffers are nearly useless for debugging 
sharing or email problems over SSL. He gave instructions on how to print 
the exchange to stdout or a log file:
http://wiki.osafoundation.org/Journal/LogSSL20070227

*wxPython*
Robin updated wx to bring in the latest 2.8 branch changes:
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007848.html

*Error exit*
Heikki explained that Chandler now exits with error code 1 if functional 
or performance tests fail, or if any script execution raises an 
exception. Making the behavior align with unit tests makes it easier to 
catch test failures from driving scripts.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007833.html

*Preview schedule*
Philippe gave an update on the preview schedule, which we changed to 
make more realistic:
- Feature complete moved out by 3 weeks
- Added 3 week performance tuning period
- Increased debug period to 8 full weeks
- Added precision to milestone definitions (agreement on what it means 
to hit each milestone)
Schedule milestones:
- Feature Freeze
   ... 3 weeks ...
- Performance Milestone
   ... 8 weeks ...
- Code Complete
   ... 2 weeks ...
- Launch
http://wiki.osafoundation.org/Projects/MilestonesDefinitionAndExitCriteria
http://wiki.osafoundation.org/Projects/ChandlerMilestoneSchedule
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007845.html

Dev
---
*Smoke tests for calendar changes, performance*
Hearing that John might do some performance work on the calendar UI, 
Jeffrey requested that care be taken if changes are made, as we don't 
have automated tests for all of the things we need to get right. Jeffrey 
listed out smoke tests he runs when making changes in the calendar. He 
also offered thoughts on optimizations, including:
- only redraw area of changed events
- avoid 2 redraws when creating new item (related to notification hints)
- only redraw in one calendar canvas (if changes only happen in one)
- fewer queries to repository for items in the current range (cache)
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007828.html

Andi mentioned an idea from IRC: events in range for the all-day and 
timed canvases could be cached on the UI event.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007829.html

*EIM: what attributes get shared?*
Morgen asked for a review of the domain model to make sure we had all of 
the appropriate fields to be shared in the EIM records. The records are 
listed/annotated in parcels/osaf/sharing/model.py. Adding attributes 
requires:
- adding fields to records (or creating records)
- implementing import/export translators
- agreeing with Cosmo team on serialization
http://tinyurl.com/26zfn8 (model.py)
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007831.html

*Deferred observers*
Andi implemented "observersDeferred".
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007832.html

*Dashboard*
A design list conversation about recurring events and the dashboard 
wandered in to the chandler-dev list. Points made by Grant and agreed to 
by Jeffrey:
- adding/subtracting reminders in dashboard should apply to selected 
row/occurrence only
- "occurrenceRemindable.userReminderTime = None" should do the right 
thing. If not, bug.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007834.html

*Byline*
Mimi noted that we don't really need a byline (beyond the updated date) 
if users aren't sharing or using email. Mimi is fine w/prompting the 
user for a name.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007841.html

*Proxied items*
Reid added a test menu item to force a conflict. Reid asked why he saw 
event handler code using "__getProxiedSelectedItems" and event updateUI 
methods using "__getSelectedItem". Grant explained that one only needs 
the proxy if one is going to change the item: updateUI code just looks 
at the item. If you are setting item attributes, you should use the 
proxy. It will record edit/update changes, and show the recurrence 
dialog where appropriate.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007836.html

*setStatusMessage*
Heikki objected to displaying an exception in the status bar. He argued 
that it can't be localized and is not understandable to end users. 
Perhaps the message should point the user to a log. Brian Kirsch pointed 
out that any ChandlerException (or descendent) can be localized. John 
believes most users won't even be able to find logs, it should be part 
of the "talk back" mechanism.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007843.html

Meetings, Announcements
-----------------------
Platform team:
http://wiki.osafoundation.org/Journal/Platform20070306

QA IRC session, verifying resolved desktop bugs:
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007838.html

Apps team:
http://wiki.osafoundation.org/Journal/AppsMeeting20070308

Desktop eng:
http://wiki.osafoundation.org/Journal/EngineeringMeetingNotes20070308

OSAF internships:
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007849.html


More information about the chandler-dev mailing list