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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
