Build, Release, QA ------------------ *Checkpoint and Release Candidate* Bear spun a trunk checkpoint on Nov 27. Bear spun RC2 on Nov 28. The bug council decided bless RC2 for the release. http://lists.osafoundation.org/pipermail/chandler-dev/2006-November/007337.html
*Alpha4 Released* We released alpha4 on Nov 30. http://lists.osafoundation.org/pipermail/chandler-dev/2006-November/007339.html *FQDN required for functional tests* Wrapping up a thread started the previous week, Dan explained that functional tests now require fully qualified domain names for tests that send email. (OSAF's SMTP servers now require this as part of an update to deal with the spam-pocalypse.) Dan linked to Jared's instructions on making sure boxes are configured properly. http://wiki.osafoundation.org/bin/view/Projects/EmailFunctionalTestsRequireFullyQualifiedDomanNames http://lists.osafoundation.org/pipermail/chandler-dev/2006-November/007320.html *Recurrence branch* Jeffrey checked in a first pass of recurrence changes designed to play nicely with the dashboard. The changes added a performance hit, in part due to the behavior of generating lots of modification items for recurring events starting in the past. The performance hit broke some tests (timeouts) and the code had the potential to mess up the office calendar data, so Jeffrey proposed a branch. Grant will add per-attribute modifications on the branch, and Jeffrey and Grant can collaborate on fixing performance and sharing pollution problems before merging back into the trunk. http://lists.osafoundation.org/pipermail/chandler-dev/2006-November/007324.html Jeffrey asked if there was any concern about creating branches due to merging difficulties. Andi and John +1'd the branch idea, noting that it is pretty painless with svn, particularly if you merge the trunk into the branch daily. http://lists.osafoundation.org/pipermail/chandler-dev/2006-November/007327.html Jeffrey backed out the first checkin and Grant created a branch. (Testers/dogfooders can subscribe to the office calendar from the trunk again). http://lists.osafoundation.org/pipermail/chandler-dev/2006-November/007330.html *Python 2.5* Heikki proposed upgrading to Python 2.5. He noted advantages: + New language features (several desired by Chandler devs) + Performance improvements + Security fixes + Can be built using free version of MSFT Visual C++ He was concerned about upgrading to a newer version being a barrier to using the platform's Python. He proposed upgrading and switching to use the MSFT compiler on windows. He also suggested requiring that Chandler continue to run on 2.4 to make using the platform Python easier. http://lists.osafoundation.org/pipermail/chandler-dev/2006-November/007341.html PJE, Katie, Andi, John were in favor of upgrading to 2.5. The same people + Grant were not in favor of supporting both 2.4 and 2.5. Grant asked if Twisted problems with 2.5 had been resolved. http://lists.osafoundation.org/pipermail/chandler-dev/2006-November/007343.html Mikeal asked why we pull down our own Python. Bear explained that since we've moved away from Python 2.3, we haven't been able to rely on having the right platform Python, and thus must pull down our own. Andi listed patches we apply (related to intel mac, readline support, windows registry, out of date berkeley db lib). http://lists.osafoundation.org/pipermail/chandler-dev/2006-December/007349.html Heikki explained that we are close to being able to use the platform Python on Linux and perhaps Mac, but we'll probably never get there on Windows. http://lists.osafoundation.org/pipermail/chandler-dev/2006-December/007350.html Heikki got Chandler running with system Python on Ubuntu. http://lists.osafoundation.org/pipermail/chandler-dev/2006-December/007353.html Dev --- *Recurrence* Jeffrey described his first pass at recurrence changes (currently on the branch): + NonRecurringNotes collection includes modifications, not just masters. Continue to add/remove only masters. + We create modifications based on triage status (dashboard features). In particular, recurring items with a start date way in the past can have hundreds of modifications (all "Done" items). We create so many modifications that it slows things down a bit, partly due to observers tracking changes. Once we have per-attribute modifications (Grant is working on this feature on the branch), we'll only track one "Done" modification, and display the most recent "Done" occurrence in the dashboard. This will also make it easier for us to ignore triage-status- only modifications when exporting to iCalendar. http://lists.osafoundation.org/pipermail/chandler-dev/2006-November/007321.html *Observers and stamps* Jeffrey explained that he only recently realized his EventStamp observer gets called every time any item is added to or removed from a collection (not just for EventStamps), as the observer is watching an attribute that doesn't live on the EventStamp. He asked if this was the correct behavior if the observer lived in EventStamp. http://lists.osafoundation.org/pipermail/chandler-dev/2006-November/007331.html Brian Kirsch explained that he doesn't really run into this case, as he's observing MailStamp attributes. He didn't disagree with Jeffrey's proposal. http://lists.osafoundation.org/pipermail/chandler-dev/2006-November/007334.html Bryan Stearns thought it would be better for the observer to check the stampedness, not the dispatch mechanism, arguing that it would add overhead to all notifications. He also pointed out that you probably want to know about unstampedness, which might get missed if you prefiltered based on the stamp. Jeffrey agreed with Bryan's reasoning. http://lists.osafoundation.org/pipermail/chandler-dev/2006-November/007336.html Meetings, Announcements ----------------------- *RSCDS: PHP CalDAV* Jeffrey pointed people at a PHP CalDAV server. Morgen noted that the develper tested Chandler against the server. http://lists.osafoundation.org/pipermail/chandler-dev/2006-November/007329.html Apps team meeting (using skype polycom): http://wiki.osafoundation.org/bin/view/Journal/AppsMeeting20061130 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
