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