Two weeks for the price of one... Build, Release and QA --------------------- *Script recording/playback as test framework* Mikeal pointed to John's recent checkin: a script recording/playback feature. Mikeal would like to use this to replace the current CATS automated tests. He's working on logging and results tracking. He wanted to get approval on a few issues: - use asserts instead of pass/fail (easy to catch in debugger) - use "test run" for the logger name instead of python package - move log output out of chandler.log - put in a StreamHandler to stdout - log level defaults: WARNING for test failures, CRITICAL for tracebacks during runs, INFO for test passes, DEBUG for test start/stop http://lists.osafoundation.org/pipermail/chandler-dev/2006-December/007450.html
Grant suggested abandoning both asserts and the previous pass/fail mechanism. Asserts won't fire during performance runs, which we'd want to run optimized. He proposed inheriting from unittest.TestCase, arguing that it has a well known, expressive API. He also noted that tests would be able to share set up code. http://lists.osafoundation.org/pipermail/chandler-dev/2006-December/007451.html Mikeal noted that the script playback feature might be used in other non-test contexts. He's not opposed to making use of unittest, would like to avoid conflating tests with scripts. Mikeal argued that most tests would be generated, not written by hand, so the well known, expressive API is less important. He asked how we'd handle tests that share data with these generated tests. He made a distinction between tests that are run by tinderbox (continuous integration) and tests selected from a file or menu. Perhaps we could run the whole suite in unittest. http://lists.osafoundation.org/pipermail/chandler-dev/2006-December/007452.html Grant argued that we'll need to write code to verify data, the generated scripts aren't going to be enough. John responded that we can compare the state of the UI and data when the script is recorded to when the script is re-run. Grant asked if this really worked well, as in many cases the state of the UI depends on the current date/time. http://lists.osafoundation.org/pipermail/chandler-dev/2006-December/007455.html Grant and John had a further discussion about using asserts vs other check methods. http://lists.osafoundation.org/pipermail/chandler-dev/2006-December/007459.html *Preview release plan* I summarized decisions about the release schedule through Preview. - No alpha6 release (alpha5 is the last release) - No further work on alpha4 - Added conflict management UI to alpha5 - Moved installers, dump/reload to alpha5 - Edit/update remains in alpha5 - Labeling/tagging and user defined attributes are cut from Preview Feature freeze for alpha5 is Feb 15. Release is planned 6 weeks later. We'll be dogfooding checkpoints after feature freeze. http://lists.osafoundation.org/pipermail/chandler-dev/2006-December/007460.html *User list* I asked if now was the time to create users list, based on Andre's earlier comments. Philippe and Aparna mentioned that they both have gotten comments from users that chandler-dev feels too technical to ask questions. Both felt we should go ahead and create a list now, as we'd get practice working with the list in advance of Preview. Davor, Reid, and Ted agreed. http://lists.osafoundation.org/pipermail/chandler-dev/2006-December/007465.html Philippe asked if we should do a forum instead of a list. Andre responded that an archived email list is good enough. http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007476.html I asked if we should create a list that focused on Chandler desktop, or a list that covered osaf.us and Cosmo as well. Andre voted for a single end-users list for Chandler/Cosmo. Marco Loregian agreed. http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007478.html *Works for me* I asked if "works for me" was the appropriate resolution for bugs that developers can't reproduce even if we know that they still happen for some end users. Philippe and Aparna agreed that "works for me" is indeed the right resolution in this case. Aparna explained that "works for me" bugs don't disappear -- QA keeps track of them and does not close them out unless a fix or resolution is validated. The "works for me" resolution gets it out of a developer's queue when they can't make any progress on it, but the bug is kept around to try and find exact steps to reproduce it. Andre suggested QA ask for help reproducing such bugs on the soon-to-be-created users list. http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007477.html *Checkpoint: Jan 2* Bear spins: http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007470.html Dan tests: http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007483.html *Copyright 2007* Bear reminded everyone to update the Copyright year to include 2007 in any source files you edit. http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007490.html *Command line options* Andi tweaked command line option initialization. If you import Globals without calling Utility.initOptions() (the code that parses command line options), Globals.options will be initialized to default values set in Utility's COMMAND_LINE_OPTIONS dir. http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007487.html Dev --- *Berkeley DB MVCC* Andi added code to make use of Berkeley DB's new feature: MutliVersion Concurrency Control. He's using a command line argument (--mvcc) to enable the feature to give us time to try it out, as it is a new feature for BDB. He'd like to make it the default in a few weeks. The feature should reduce deadlocks, offer better read throughput, and result in better memory cache usage. He'd like to run with the flag on the performance tinderboxes to see if we notice a speedup. More details in Andi's message: http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007481.html Andre noticed a big improvement. In particular, he noticed that sync/restore of his 9 collections is much improved. http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007484.html *Prune your repository view* Andi added an attribute allowing a repositoryView to specify the "pruneSize". The view is pruned down to that size at commit() and refresh(). He also added a --prune command line option to control the default pruneSize for a view. http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007489.html Meetings, Announcements ----------------------- QA session testing Cosmo: http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007473.html No apps team meeting. Status: http://wiki.osafoundation.org/bin/view/Journal/AppsMeeting20070104 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
