Build, Release and QA --------------------- *Continuous tests for Cosmo and Chandler* Mikeal posted a proposal for a continuous test system on the cosmo-dev list. http://lists.osafoundation.org/pipermail/cosmo-dev/2006-September/001600.html
*Checkpoint, Sept 25* Bear spun the checkpoint: http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006956.html Dan tested it: http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006981.html *Alpha4 Stabilization* 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. http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006990.html *Bugzilla tip* Mikeal pointed out that you can "watch" a user on bugzilla and get bugmail on their bugs. Prefs->Email Preferences http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006992.html *Licensing* Brian Kirsch asked about licensing guidelines. Philippe explained there is no easy answer or shortcut, but gave some rules of thumb. http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/007039.html *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. http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/007003.html *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. http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/007022.html *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). http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/007041.html Tests and Tinderbox ------------------- *Functional tests* Dan asked how people are running functional tests; several folks responded. Thread starts here: http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006957.html *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: http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006967.html *Meeting followup* 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. http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006991.html 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). http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/007030.html Dev projects ------------ *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[16] or Text[36]). 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 feedback, thoughts. http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006936.html 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 never change. http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006966.html Grant liked the proposal overall. He was curious about the reason for length/size restrictions for Bytes, Text and Integer. http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/007013.html *Disappearing events* 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. http://lists.osafoundation.org/pipermail/chandler-dev/2006-October/007051.html 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. http://lists.osafoundation.org/pipermail/chandler-dev/2006-October/007056.html *In/Out Collections* 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". http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/007034.html Meetings, announcements ----------------------- Call for papers for PyCon 2007. Submission deadline Oct 31. Apps meeting: http://wiki.osafoundation.org/bin/view/Journal/AppsMeeting20060928 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
