[Chandler-dev] [Sum] Feb 12 - 18

Fri Apr 6 22:00:27 PDT 2007

Build, Release
--------------
*Weekly checkpoint*
Bear spins:
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007671.html
Dan tests:
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007685.html

*Plugin (egg) build changes*
Bear explained that EggTranslations moved to external/, and is now 
installed in the same way as other libraries. zope.interface is now 
delivered as an egg. Plugins are installed in CHANDLERHOME/plugins. A 
"make distclean" is required, as is a "rm -rf plugins".
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007707.html

Andre promptly ran into problems after not running distclean, which 
revealed a "backwards" app dependency on the EventLogger plugin. Grant 
pointed out that we'll need to fix all such dependencies.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007724.html

*Vista before preview?*
Jared asked for the plan of record.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007735.html

*Freebusy cut from Preview*
Jeffrey proposed removing the free-busy feature from Preview. Given 
various sharing improvements and other changes to the app, it would take 
~1 week to fix it. Mikeal questioned its usefulness without scheduling 
features.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007750.html

QA, bug discussions
-------------------
*More index woes*
Andre brought up another index mismatch problem, this time possibly
related to floating events and timezones.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007664.html

Andi suspected an issue with the timezone dialog. Andi explained the
error occurs when an item is in an index but not in that index's
collection. He suspects an interaction with the timezone dialog and lost
notifications. He noted that this bug is _not_ the same as the problem
with the triage indexes going out of sort order.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007665.html

Jeffrey explained the dialog behavior.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007672.html

Andi observed and fixed a merge bug related to datetime/time values and
timezone changes.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007673.html

*Startup, restore*
Andre and Dan discussed Bug 8083, a problem with startup on windows due 
to spaces in paths. (Restore ends up restarting Chandler, so Andre was 
seeing the bug in this case). Andi fixed the bug.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007696.html

*Search*
Andre found a bug with search, which John was able to reproduce. John 
thanked Andre for running the debug version, which helped uncover the bug.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007747.html

Dev
---
*EIM triage status*
Morgen proposed combining triageStatus and triageStatusChanged into one 
field for EIM, so that they change atomically. He explained the 
combination is just for transmission (not stored that way).
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007678.html

Jeffrey later added a bit to the field: an auto-triage-state flag.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007756.html

*Plugins*
Ted argued that we should invest in documentation over plugin 
infrastructure, as lack of documentation is the bigger barrier for 
people developing plugins. PJE explained that Andi's proposal consists 
of the minimal set of infrastructure work to accomplish our other build 
goals -- we're just using what we already have.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007716.html

Davor noted that he'd prefer to be able to just cd to a directory to 
peek at source. PJE explained that the source is easily available, 
including source to plugins from third parties.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007711.html

Jared asked about metrics from CheeseShop, and if we can direct 
downloads to our sites. PJE answered: daily raw download counts. Yes, 
downloads can be directed to our sites.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007734.html

Philippe had a similar concern as Ted. Heikki re-pointed out the small 
cost of the proposal. (Future Katie knows that Andi implemented the 
proposal).
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007733.html

*Performance*
Heikki observed a big regression in the first time a view switches, and 
an improvement in subsequent view switches. We don't want the first time 
to be slow, but the second case is more common. What to do? Measure one 
or the other? Both?
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007680.html

John explained that the situation is more complicated. Scenarios:
- (1) copy new tree of blocks, new contents
- (2) cached tree of blocks, new contents
- (3) cached tree of blocks, no attaching new contents
He's tried to make (1) more rare, which makes (2) more common. The test 
doesn't measure each case, or a mix of cases found in practice.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007681.html

Heikki asked if it covers everything already loaded into memory vs 
needing to be loaded from disk? Perhaps we can't cover all cases. Andi 
wondered if Heikki and John were looking at the right things. He 
explained an issue with BerkeleyDB that slows down repository I/O after 
importing the 3k event calendar. He's trying to get more info/help from 
the Sleepycat folks. Increasing the repository cache is a workaround.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007683.html

John proposes measuring time switching between two views (dashboard and 
calendar) after each view has already been previously visited.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007694.html

*Performance update*
Heikki summarized recent performance actifiy. He added several tests to 
measure the second time performing an action. For these cases, we now 
have the slowest and the fastest time for the cases. He also modified 
the calendar scrolling case to move several units instead of one. He 
wrote a "busy dev guide to perf optimization". Heikki listed out some 
significant regressions (likely due to new features landing) and a few 
improvements. He mentioned scenarios the tests don't hit: mvcc (shows up 
with several background tasks) and startup slowdown with certain data sets.
http://wiki.osafoundation.org/Projects/BusyDevelopersGuideToChandlerPerformanceOptimization
http://builds.osafoundation.org/perf_data/trends.html
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007749.html

*Chandler as CalDAV client*
Morgen explained three options for handling CalDAV now that we're moving 
  to the EIM sharing model.
- (1) Maintain old CalDAV code, ripping out XML fork, time-travel-for-merge
- (2) Maintain old CalDAV code, but put merge/conflict detection 
responsibility on calendar code
- (3) Modify ICalendar code to go on top of EIM. Break ICalendar down 
into EIM records. Participate in EIM's merge and conflict resolution.
(3) is the long term ideal. Future conduits could also be added, getting 
merging and conflict handling as well.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007692.html

Grant and Andi preferred (3), thinking we'd avoid some nastiness and 
that it shouldn't be too hard to tackle.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007700.html

*Recurrence*
Back to the future, Jeffrey summarized options for getting the right 
table view refreshes for changes to master events inherited by many 
occurrences. Set occurrences explicitly? Repository propagatation? 
Explicit call to Refresh?
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007701.html

*Dump and Reload*
Katie summarized todo items from a meeting.
- Bear and PJE to figure out serialization format. (Future Katie knows 
that we landed on pickle, after that was easy for Morgen to get going.)
- EIM translators, tables for different areas of the domain model.
- Code that drives dump/restore, menu items (Morgen)
- Startup/installer code (Bear)
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007704.html

Andi mentioned the PyLucene index.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007713.html

Morgen created a Wiki project page to track the work. Philippe added 
tasks in Bugzilla.
http://wiki.osafoundation.org/Projects/DumpReload
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007732.html

*Sharing update*
Morgen gave a summary of the state of sharing before he went on 
vacation. The summary includes instructions on how to try out the new 
sharing from test menus. (Future Katie knows these have changed a 
little, but one might be able to piece it together). Morgen pointed out 
that the "pim" link available from Cosmo's "account browser" is the 
"bookmarkable url" that is useful directly in a browser or eventually 
for subscribing to the new sharing accounts.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007717.html

*Tags*
Markku passed along a discussion with Viksit about autotagging in Chandler.
http://wiki.osafoundation.org/Projects/AutoTagsProject
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007715.html

Philippe explained that tags have been cut from Preview, so autotagging 
might not make much sense and the core team don't have many extra 
cycles. Palm and Oracle calendar sync are open projects, help with these 
would be most welcome.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007736.html

Meetings, Miscellaneous
-----------------------
Cosmo QA IRC session:
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007702.html

Apps team weekly status:
http://wiki.osafoundation.org/bin/view/Journal/AppsMeeting200701214

Darshana Chhajed added as a new Chandler committer.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007738.html