Build, Release -------------- *Weekly checkpoint* Bear spins: http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007594.html Dan tests: http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007601.html
*New wx tarball* "make" will get you the new wx tarball, with fixes for linux drag and drop, speedier two finger scrolling, an os x list control cosmetic issue, and a script recording bug. Also adds missing xrc styles for wxHyperLinkCtrl. http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007599.html *Where is my repository? How can I use different repositories?* Answer to first question here: http://wiki.osafoundation.org/twiki/bin/view/Projects/ProfileDirectory Andi added two new menu items under Test-Repository. - "New Repository": restarts Chandler with a new repository in the chosen location - "Switch Repository": restarts Chandler with existing repository in the chosen location. If there is no repo at that location, it clones your existing repository into the new location. More details here: http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007644.html *Schedule* Philippe gave a schedule update, including outlining remaining phases/deadlines for Preview. (Dates no longer correct, so omitted from summary). - Feature Freeze (Feature work stops. Performance work starts. Deadline criteria: no "task" bugs in bugzilla.) - Code Complete (Major code in, including perf and feature tweaks. Deadline criteria: perf targets hit, no feature tweaks needed.) - Code Freeze (All bugs fixed. Deadline critera: no more than 10 blocking bugs to enter final phase.) http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007658.html QA, bug discussions ------------------- *Vista* John ran a recent build on Vista, which crashed after launching. He was able to run from the command line without any problems. He also tried 0.6, and ran into various problems (deadlock bug, splash screen). http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007603.html *Testing data migration* Aparna sent out a notice about a QA session to test migration to Cosmo 0.6 (in preparation for upgrading osaf.us): http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007606.html Jared gave more context about how the sessions run: - osaf.us remains the live production instance. Changes made to lab.osaf.us are thrown out. You can test your account freely on lab.osaf.us during the test session without any impact on your real data. - Only you can access your account on lab.osaf.us. All security policies protecting live data at osaf.us apply to lab.osaf.us. - "spot checking" testing helps us validate migration from the Cosmo 0.5 schema to the Cosmo 0.6 schema http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007609.html Jared and Aparna agreed that the safest path for the test session would be to test lab.osaf.us with a "fresh" Chandler profile, leaving your original Chandler pointing at osaf.us. http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007615.html *Recurrence bug?* Andre noticed the end date of a recurrence changing by extending one day, with no apparent action on his part. Dan couldn't reproduce the bug. Timezones may be involved. Andre was trying for reproducible steps, no bug logged. http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007614.html *Index woes* Andre asked about errors indicating that triageStatus and displayDate subindexes were out of step (e.g. 'not sorted properly', 'rebuilding'). Bryan Stearns pointed out that we have a bug (7324), but no good set of steps to consistently reproduce the bug. Andi observed that dangling refs are getting introduced in the repository somehow (which eventually lead to the KeyErrors). Isolating a simple set of steps would be invaluable. Thread starts here: http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007636.html Dev --- *Mail in Preview* Brian Kirsch checked in a major set of email work, and wrote up a summary of the changes. The goal for preview: allow people to get some mail messages into Chandler, and assume that the user continues to use their current email client. Chandler no longer downloads all email from an IMAP inbox or POP server. It now scans for messages with "Chandler" headers (mail sent by Chandler clients). It also allows the user to set up "Chandler" IMAP folders. The user can put emails from into these folders on their favorite IMAP client, and Chandler will pick them up. Brian also reworked the Account Preferences Dialog, cleaning it up and adding features like "autodiscovery". More info in Brian's message: http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007602.html *Plugins* Katie assumed we were moving plugins from the end-user release. Heikki gave a proposal for trimming the end-user release, including removing plugins, and leaving the developer release as is. http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007608.html Philippe liked Heikki's proposal but expressed concern about developer resources. Heikki responded that he didn't think most tasks were very expensive. He mentioned removing menus as a tricky bit, suggesting that menus should appear automatically if used by any plugin. PJE suggested accomplishing this by providing APIs like 'getTestMenu(view)', returning existing menu item or creating and returning it. Plugins which add menu items can use the return value of the parent. http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007613.html John noted that many test menu items are useful for tracking down bugs with users, and would like to see them remain in the end-user release. He proposed a hidden key combination to toggle the menu. Heikki thought the test menu code should live in a plugin. John thought the code to implement the test menu is trivial, so why remove all of it? He gave "check repository" as an example of something we should leave in. He thought we could take a pass through the menu to remove some that are clearly not useful for development. http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007620.html Katie agreed that some items from the test menu should remain in the end-user distribution. She asked John for a list of items he'd like to remain. She noted her alpha5 bug to move "test" code to a plugin, explaining that she could factor out certain menu items and leave them in the core. She listed out items she'd like to see available. Davor added 'save/restore settings' to her list. http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007629.html John wanted some way for developers to unzip or download the parcels, from the end-user release. Andi agreed that eliminating the plugins altogether would be counter productive, though we need to at least do something to "turn them off" -- don't leave Flickr active in the background. Heikki explained that disk or download footprint isn't his concern, he's concerned about plugins that use up memory, slow down startup, are periodically active on the network, etc. http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007625.html Brian Kirsch explained that the Egg-Translations plugin is required, and shouldn't be removed from the end-user (or any) distribution. http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007619.html Andi proposed renaming 'Experimental' to 'Plugins'. Heikki suggested 'Tools' -- move other items from the 'Test' menu. Katie suggested 'Demo'. She agreed that a 'Tools' menu makes sense for items we want to keep around in all releases, like "check repository". She explained that the long term model is not for plugins to be segregated to one menu, but to be integrated into the app. In the short term we don't have the time to do that properly. Andi asked: why a plugin for 'Tools'? http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007632.html Katie started a related thread on the design list. http://lists.osafoundation.org/pipermail/design/2007-February/006301.html PJE revealed a misunderstanding on Katie's part. He explained that plugins are shipped as .egg files, placed in an appropriate directory. We should think of projects/ much as we think of externals/ -- not to be shipped with a production Chandler instance (they are part of the *build*). "Activating" or "installing" a plugin is about putting the .egg file in the right directory where Chandler can discover it. He posed the question as: do we want to ship the .egg files and do we want them activated? He noted a performance gain on startup with the .egg files vs the projects/ directory -- we could consider building up parcels/ as an .egg. He explained that "setup.py develop" and "setup.py install" are the needed tools for plugin development, including getting the source. setup.py also provides the mechanism for registering/uploading a plugin. A menu item allowing devs to pull down plugins from CheeseShop and we have all the infrastructure we need to develop, distribute, and deploy user-contributed plugins. http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007653.html Katie asked if we should go the CheeseShop route for Preview. Andi responded in the affirmative. http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007655.html Andi and PJE discussed further in IRC, and came up with a proposal. - Use CheeseShop for publishing plugins - Don't ship "projects" directory, create "plugins" directory for installed .eggs. - Move indispensable projects (translations) to "external", "internal" or "parcels" - Add plugins menu to point to CheeseShop - Plugins menu can scan "plugins" to know which plugins are available and which are actively installed/running http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007656.html Heikki described a system similar to Mozilla's: put the plugins in the source tree if you have write access, otherwise put them in the profile directory. Something simpler would be ok for Preview. He recommended looking at the Firefox UI. He observed that Firefox has a huge number of extensions, and is not sacrificing end user experience or download size. He's in favor of scrapping everything not needed by the end user. http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007659.html *EIM and Recurrence* Jeffrey gave a scenario we need to support: a master event is just an event, but some modification is also a task. The current plan was to pass just the master to the translator for export, expecting the master to yield modifications. Jeffrey asked for a mechanism for sending the modifications to appropriate translators. http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007641.html PJE offered two options, storing a second translator to handle modifications, or calling the same translator and detecting whether the event was a master event or modification. Jeffrey and PJE agreed the latter was fine for now, though Jeffrey wondered if this would be confusing for future parcel writers -- they will be _required_ to distinguish between masters and modifications for this to work correctly. http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007649.html *EIM domain model* A Cosmo thread about EIM and recurrence wandered in and out of this list. Thread starts in chandler-dev here: http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007648.html Morgen gave a summary of null related values in EIM: - None/Null (field has no value): <element /> - Empty (string or list field has an "empty" value): <element empty="true" /> - NoChange (in diff records, field hasn't changed): not serialized, the absence of an element is an indicator of no change Morgen asked: if we have a master event with a reminderTime, and a modification doesn't have a reminderTime, is that field represented as "None/Null" or "Empty"? Morgen suggests that "None/Null" could indicate the modification inherits from the master, and "Empty" could indicate an explicit lack of reminder. Morgen asked other questions: What does "Empty" mean for an Integer type? Does a "None/Null" value for "Location" mean we remove the item's location attribute or set to None? What would "Empty" then mean? Jeffrey agreed with the proposal: Empty indicates specific removal of a field, None/Null indicates the field should inherit from the master. Jeffrey noted there is no way to distinguish between an empty string in a modification field and removal of the entire field with this proposal, but thought we could live with it. Jeffrey and Randy agreed on a strategy for icalendar and EIM: - DTSTART and DTEND should go in icalendar even if not changed - DTSTART and DTEND should _not_ go into EIM modification records unless start time or duration is changed by the modification. - If an event is created by CalDAV including start/end time for all modifications, Cosmo should strip away unnecessary times when Chandler syncs. http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007650.html Brian Moseley thought the proposal wasn't quite right. After further conversation in IRC, Brian Moseley summarized a new proposal. A modification attribute has three possible states: - has a value - has no value (None/null, or <element />) - is "missing" <element eim:missing="true" /> Only modifications can have "missing" attributes -- this indicates the attribute should be inherited from the master item. Cosmo will copy the attribute value from the master when exporting the modification to iCalendar, CalDAV. Alarms on event modifications can also be "missing". http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007660.html *Conflicts API* Morgen sent out documentation about the conflicts API, for use by the conflict resolution UI. API documentation on sharing wiki page: http://wiki.osafoundation.org/Projects/SharingProject#Conflicts%20API Usage in doctests: http://viewcvs.o11n.org/chandler/trunk/chandler/parcels/osaf/sharing/EIMML.txt?view=markup Philippe asked if a "field" mapped to an attribute. Morgen explained that a "field" can be a spectrum, ranging from an entire item to an EIM field. As a short term step, the current granularity is an item (to allow testing with the API, which will not change). Once the implementation is finished it will be an EIM field, which is essentially an attribute. Morgen gave the record types currently defined. He explained that at some point we might link fields that need to be rendered, applied and discarded as a unit. http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007668.html Meetings, Miscellaneous ----------------------- Platform team: http://wiki.osafoundation.org/Journal/Platform20070206 Apps team: http://wiki.osafoundation.org/Journal/AppsMeeting20070208 Chandler mtg: http://wiki.osafoundation.org/Journal/EngineeringMeetingNotes20070208 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
