[Chandler-dev] [Sum] Sept 25 - Oct 1
Katie Capps Parlante
capps at osafoundation.org
Wed Nov 1 09:50:00 PST 2006
Build, Release and QA
*Continuous tests for Cosmo and Chandler*
Mikeal posted a proposal for a continuous test system on the cosmo-dev list.
*Checkpoint, Sept 25*
Bear spun the checkpoint:
Dan tested it:
Philippe requested that everyone focus on stabilizing Chandler. The
criteria for releasing alpha4 is that it be stable enough for dogfooders
to use, and we were still running into a bunch of serious bugs. We
decided to slip the schedule 2 weeks (pushing to Oct 17). Philippe asked
for more people to dogfood Chandler -- even having an instance running
in the background was picking up significant bugs. Subscribe to the
office calendar. Turn logging on. Set IMAP/SMTP accounts. Philippe later
explained that either the most recent checkpoint or the latest trunk
build would be adequate for testing/dogfooding.
Mikeal pointed out that you can "watch" a user on bugzilla and get
bugmail on their bugs. Prefs->Email Preferences
Brian Kirsch asked about licensing guidelines. Philippe explained there
is no easy answer or shortcut, but gave some rules of thumb.
*Congress adds a task*
Jeffrey reminded everyone that Congress changed US daylight savings time
dates. We best fix this before March. Bear and Andi figured out that ICU
3.6 has the updated database, as well as charset detection. Andi will
work on an upgrade. Brian K noted that charset detection will indeed be
useful for email without character set headers.
*Pydev in Eclipse*
Heikki got Pydev working in Eclipse. He was able to debug Chandler
threads. Its a bit slower than Wing or Komodo, but still usable.
*3rd party plugins, test egg*
Katie responded to an older thread about keeping example egg/parcels out
of the end-user download. She suggested that egg
download/install/uninstall integration into the UI would make a good 0.8
feature, especially if we start to emphasize plugin parcels/eggs in
0.8/Preview2. She agreed to move the test code into its own plugin egg
for alpha5 (Bug 4617) and include the testing skins in the egg (Bug 6901).
Tests and Tinderbox
Dan asked how people are running functional tests; several folks
responded. Thread starts here:
*Functional test failures*
John's request for info about a functional test failure sparked a
conversation about exceptions not being caught and reported as errors by
the framework. John and Heikki suggested that any output to stderr
should be interpreted as a test failure. This strategy would catch one
case involving exceptions thrown by Python calls invoked by C/C++ (e.g.
wxWidgets), as the exception is written to stderr. Mikeal suggested this
might be error prone if non-failing cases write to stderr. John and
Heikki explained that those prints should be removed. Thread starts here:
Following up on the previous week's meeting about Tinderbox/test suite
frustration, Dan outlined issues and possible solutions. (1) A new
agreement on policy when tinderboxes go red or orange for a long period.
He restated Bryan's proposal. (2) Improvements to ChandlerTestLib and
the functional test. Dan gave a full list of suggestions he heard. (3)
Improvements to how tests are logged. Again, Dan gave a list. (4) Fix
app_ns to avoid misleading errors. (5) Improve cycle times with faster
hardware. (6) Rewrite do_tests in Python.
Bear agrees with Dan's restatement of Bryan's proposal for long
red/orange situations. Dan had listed the option "Regularly run tests on
their own". Bear responded that we could do this if we had a manifest of
tests to run or ability to query for test names. We'd want to avoid the
tool falling out of sync with current tests. Bear +1'd consolidated
chandler/twisted logs. He pointed out that each test can output
parameters to the log so that every run is self documenting. Bear
explained that plans for (5) and (6) are in the works. He suggested a
wiki page to collect requirements for (6).
*EIM/Sharing type definitions*
Phillip Eby summarized a meeting covering interoperable types for Cosmo
and Chandler. They proposed 5 primitive types (Bytes[length],
Text[length], Lob, Integer, Datetime). Text in bytes of UTF-8 encoding,
Lob does not include mime-type info, Datetimes include timezone name and
UTC offset. Primitive types can be extended with "typedefs", which have
URIs (e.g. UUID is Bytes or Text). Types in records can
optionally be associated with a typedef/URI (implying semantics). EIM
based systems should be able to handle any type (given the primitive
representation) or can optionally provide better support for particular
types. Phillip gave examples and discussed how type info would affect
the API. Open issues included self-references, field-to-field
references, primary key, and type representation changes. PJE asked for
In a follow up message, PJE gave an alternative record type declaration
that addressed the primary key issue, and field-to-field references for
same or different record types. An implied constraint: primary keys can
Grant liked the proposal overall. He was curious about the reason for
length/size restrictions for Bytes, Text and Integer.
Sheila had pointed out that Esther and Mitch were seeing cases of
disappearing events, and asked dogfooders to try and reproduce this
case. Jeffrey reproduced it, and observed that imported recurring events
don't reliably create a first occurrence. This causes problems,
including masters not being included in masterEvents and not showing up
on the calendar.
Grant explained that the _share_importing flag disables updating sparked
by recurrence-related attribute changes. Grant suggested changing the
masterEvents filter. He noted that it feels a bit off to require one
occurrence to be generated. He and Jeffrey agreed that the reminder code
currently requires it.
Bug 6857 sparked a discussion about how to properly handle In/Out
collections and their relationship to "Mine". Morgen explained that the
current implementation (based on the isOutbound flag) didn't really
handle shared emails properly. Brian Kirsch specified the desired
behavior: "In" should contain emails where the "me" address is in the
"to" or "cc" field. "Out" should contain emails where the "me" address
is in the "from" or "reply-to" field. Morgen and Brian agreed that the
Mail Service would manually add messages to appropriate collections
based on the headers. Taking this approach vs a filter would be better
for performance reasons, and has the advantage that it handles the case
where the "me" email address changes over time. In/Out collections will
remain in "Mine".
Call for papers for PyCon 2007. Submission deadline Oct 31.
More information about the chandler-dev