Build, Release, QA
------------------
*wx tarball*
Robin updated the build with a new wx tarball. See message for a list of
features. One highlight is that the issues with the native toolbar on OS
X are all fixed.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006800.html

*Alpha3/Alpha4 sharing compatibility*
Grant has translations for stamping-as-annotations events to old-style
events. Grant has unit tests for this case working on his branch. (This
should cover the known issues with alpha3/alpha4 compatibility.)
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006798.html

*Network errors in tests*
Heikki noted that we have some tests that try real connections to
services outside of OSAF. We have no control over these services, and
occasionally the tests fail. Heikki proposed wrapping each network call
in code that tries the call a few times. Another alternative would be to
not make any network calls in tests.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006828.html

Andi liked this proposal, and asked that we also have a command line
option to disable tests that access the network. This would help if
someone was running tests offline or with a slow connection. Heikki
noted that its a bit messier to make this work for unit tests. Andi
thought a functional test command line option would be a useful step.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006831.html

*Tinderbox more readable*
Heikki explained how tinderbox works wrt logs, in the context of
thinking about how to make them more readable. Log data can get lost if
Python crashes -- no functional test output. If there is a Python
shutdown crash, the tests may pass and the log may look fine. It may go
undetected, or the crash may get detected and just add one line "tests
failed". The tinderbox server creates an HTML page with the full log.
The top has links to errors, generated by parsing for keywords like
'error', 'warning', etc. Heikki also noted that the logs are long and
verbose. Heikki asked for ideas for improvement.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006850.html

Bryan suggested using the native Python logging mechanism. Tinderbox
could use its own logger object, perhaps resulting in fewer
false-positive errors. Diagnosis would be easier, as log output would be
combined in correct chronological order. Bryan suggested that verbose
output was not the problem -- false positives are the problem. Bryan
asked for more descriptive error messages in the case where we detect
Python crashing.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006852.html

Heikki thought he could make changes for the cases where we are getting
confusing output when Python crashes. He went into more detail about the
concatenated log, listing all of the log outputs:
chandler.log/twisted.log (Python logging), Tinderbox client script, unit
test output, functional test output, performance test output,
make/compiler output. He noted that we use the generic unix error parser
that comes with Tinderbox. He'd rather not maintain a hacked tbox, so
he's wary of changing it.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006853.html

Bryan explained that functional test output is the hardest to deal with:
not integrated with chandler.log, and tbox isn't doing a good job of
producing an index based on the output. Bryan noted that he made some
modifications to the error parser to deal with pre-cats output. He felt
it was a good investment to maintain these kinds of changes as we
upgrade tbox.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006855.html

Bear feels that the unix parser is actually the best parser to deal with
the variety of output. He gave more details about how the tests run, and
suggested that we collect all of the developer feedback and coordinate
the changes.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006856.html

i18n, l10n
----------
*Finnish and French localizations*
Philippe and Markku completed localizations of Chandler in French and
Finnish. Given the tools, the process seemed to take about one working
day. Markku noted a series of small bugs and issues.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006804.html
Heikki encouraged Markku to file bugs and submit patches. (The thread
continues on to discuss the fixes.)
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006805.html

*float() exception using French locale*
Philippe observed a weird exception using the French locale (Bug 6688),
apparently from float(). PJE theorized that a race condition could occur
if the locale was being switched on another thread running pure C/C++
without holding the GIL. Needless to say, this condition would be hard
to reproduce. Also, no one could really explain how the locale would be
changing from another thread. Andi suggested using PyICU number parsing
routines, Jeffrey found that solution unsatisfying (not helpful for
Python programs not using ICU). Thread starts here:
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006814.html

Intern, SoC projects
--------------------
*Date/time autocompletion*
Brian Kirsch added a section to the DateTimeParsing wiki for
localization. He asked for information about how the module handles
localized parsing. Bear noted that localization information from
Chandler can be used to update/modify localized text used by parsedatetime.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006839.html

Development
-----------
*EIM/Sharing API*
Phillip organized a meeting to discuss the type vocabulary for EIM.
Prior to the meeting, there was a discussion about using a subset of
XSD, how types mapped to Cosmo and Chandler, and SQL types.
http://wiki.osafoundation.org/bin/view/Projects/ExternalInformationModelDataTypes
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006806.html

Brian Kirsch brought up the idea of using EIM with a mail transport.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006833.html

Grant noted that this wouldn't be interoperable -- perhaps only for
"Chandler" specific parts of the message. Brian explained that he was
wary of asking individual items to know how to convert themselves to RFC
2882 messages.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006838.html

*Expanding edit fields*
Reid was working on some ideas for expanding edit fields in the detail
view (the ability to add more or fewer fields). He was running into some
issues with the functional tests and asked for feedback on his patch.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006844.html

Meetings
--------
Apps team meeting
http://wiki.osafoundation.org/bin/view/Journal/AppsMeeting20060914
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev

Reply via email to