Build, Release, QA
------------------
*Test failures*
John committed a change that revealed assumptions in functional and
performance tests. In particular, tests assumed the calendar view would
be displayed when the calendar button is pressed -- no longer true when
viewing the Dashboard collection. Individual tests needed to be
corrected (not just the first test in the suite), both functional and
performance tests.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006761.html
*Feedback analysis*
Heikki wrote up an analysis of the first batch of feedback reports.
http://wiki.osafoundation.org/bin/view/Journal/FeedbackAnalysis20060905
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006768.html
Heikki noted that people still need to file bugs for errors that bring
up the feedback dialog. It is still helpful to send the feedback
reports, as this helps us tune the system and gives us overall data
about Chandler stability. Heikki proposed a goal of mean time between
failure at over 8 hours.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006772.html
Heikki modified the feedback dialog. The "Required" tab contains an ID
that can be used in bug reports to link back to info sent to the server.
We also save every sent feedback report in the profile directory.
Heikki also added a Restart button, which relaunches Chandler with the
startup options dialog. The Restart button may not work on Mac, and has
a locale related glitch on Linux.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006794.html
*Command line options to support testing and debugging*
Bryan made changes to command line options. (1)
--catch=(normal|tests|never) replaces --nocatch, giving the option of
removing both the test suite exception handler as well as the app's
exception handler. Removing both allows debugging of functional test
failures. (2) -T/--chandlerTestSuite runs the test suite -- the shorter
options help when one is running these from Wing. (3) -t is now
associated with --chandlerTests (a common operation), not --testScripts
(probably doesn't make sense to run all scripts anymore).
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006779.html
*Checkpoint*
Dan's report for the Sept 6 checkpoint:
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006788.html
Parcels
-------
*Java development*
Marco Legorian asked if he could write a Chandler parcel in Java. PJE
and Andi gave the short answer "No, not possible" as well as longer
answers about incorporating Java code in Python.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006757.html
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006758.html
*Not all parcels in end-user distribution*
Heikki recommended that we move tests, tools and any other similar code
that is not strictly needed to run Chandler into separate eggs not
included with the end user binaries. We could save 4 MB on Windows,
possibly more on other platforms. He suggested creating a menu item to
find parcels from Cheeseshop automatically. (PJE explained how this
would be fairly easy using easy_install earlier in the thread).
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006778.html
Development
-----------
*Sharing format API*
Morgen forwarded questions he'd asked PJE about the sharing format API,
along with PJE's responses. When would you pass "sharing.NoChange" to
loadItemByUUID() as the UUID argument? It could get passed through as a
field in a record -- say if the lastModifiedBy field of some record was
"NoChange". Do we just assume that Cosmo and Chandler happen to match
wrt type, given no type info encoded in the record? There are other ways
to document or transmit type information. Morgen included pseudo code
for how the sharing layer will use the API. The sharing layer downloads
a Cosmo resource containing a bunch of records, which belong to various
sharing.Schemas. The sharing layer processes these by instantiating the
appropriate sharing.Schema objects and calling startImport() on those
objects. It calls importRecord() for each record, then finally
finishImport() on each sharing.Schema object.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006759.html
Brian Moseley asked about mapping the EIM format to an xml schema, and
how to do that given that Cosmo won't necessarily know the semantics of
the data. He also asked about preserving type information. PJE suggested
that we could make do by representing the data directly in EIM form, and
skip adding the extra XML format. A type vocabulary, a 3-field record
structure (table, column, type), uniqueness and inter-table constraints
would be enough to construct tables in Cosmo's database to store the
exact EIM data. Given that Cosmo and Chandler will need to understand
EIM, store any needed schema information as additional EIM records (with
hard-coded schemas), and skip the XML format.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006784.html
PJE gave an example:
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006786.html
Ted noted that we'll want likely diff processing capability for good
sharing performance, so we ought to work out the key management issues.
He also would like to address the type vocabulary sooner rather than
later. Cosmo will be looking at new infrastructure to move away from
hard-coding event types, so might as well get the type details right
from the start. PJE proposed making the first positional argument be the
key. A multi-field primary key could use parens to include multiple
fields in the first argument. He listed a few type vocabularies we could
start with -- some more convenient for Chandler (Python, repository),
others for Cosmo (Java, SQL) and others not particularly convenient for
either (XML Schema).
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006793.html
*Pysizers*
Travis delved further into non-resident memory usage, making use of proc
on Ubuntu. He was looking for ideas on how to interpret some of the results.
http://wiki.osafoundation.org/bin/view/Journal/ProcFilesystemMemoryExploration20060905
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006763.html
*Dividing schema changes*
Jeffrey proposed tracking three different kinds of schema changes with
separate version numbers: (A) data (B) index definitions (C) UI schema
changes. B and C could be repaired by re-indexing existing items and
rebuilding the UI.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006764.html
*Simple guide to localizing Chandler*
Brian Kirsch wrote up instructions for localizing Chandler. Philippe
tried it out (French) and documented his experience. Markku did a
Finnish version and added notes as well. (Bug 6657)
http://wiki.osafoundation.org/bin/view/Journal/LocalizationNotes
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006795.html
Meetings
--------
Platform team meeting
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006774.html
Apps team meeting
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006782.html
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
