Build, Release and QA --------------------- *Checkpoints and release candidates* While we have the branch and are working towards release candidates, the checkpoints will be off the branch and we won't do checkpoints on the trunk. We did a release candidate on Friday, July 14.
Monday, July 10 checkpoint report: http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006281.html Friday, July 14 checkpoint report (release candidate): http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006360.html *Feedback on Checkpoint Status* Dan asked for comments on the checkpoint reports: are they useful? what could be left out? what could be changed or added?. He's modified the format to separate bugs found during checkpoint testing from new bugs that have accumulated since the last checkpoint. Bear replied that he finds them useful and likes the recent changes. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006285.html *Target Milestone and Bugcouncil Triage* Jeffrey liked the proposal that we use the "Target Milestone" field as the flag to bring a bug to bugcouncil's attention. He asked that we change '---' to something more clear, suggesting "Request Bug Council Triage". Mikeal noted that he's used versions of bugzilla where "triage" was used as the default for status, priority, severity, and target milestone. As many fields get left with the default, it would be nice to force bugcouncil to set these fields, and allow them to be unset to ask bugcouncil to look at the fields. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006287.html *Commit comments* Jeffrey asked for a bug summary (not just the bug #) in commit comments. Andi objected to duplicating data. Bryan, Grant, Ted, and Philippe all chimed in noting that the small redundancy has a lot of benefit for those following the commits list -- the summary is useful information for a quick glance at which commit mails to read more carefully. Andi liked Grant's suggestion of writing a script to pass stdin as the svn commit messsage, get the revision # from the output, and then update the bug with both the comment and the new revision (not unlike subzilla). Andi will run with this idea (instead of others discussed in the thread) as it has minimal impact on the rest of the system. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006279.html http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006291.html *Subzilla* Jeffrey added more options to Subzilla, and laid an egg for easy installation. You can now close a bug or post a diff using subzilla; Jeffrey gave more detailed instructions on use and installation. Brian K found a problem with the install, subsequently fixed by Jeffrey. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006350.html *setuptools and easy_install* Phillip explained that Jeffrey could include ez_setup in his distribution. "python setup.py install" will install setuptools and easy_install along with your package. Phillip included links to setuptools docs. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006351.html Phillip and Reid had an exchange about where easy_install should put scripts. (I won't summarize the details about distutils internals and why this is trickier than it might look -- more in the thread). Phillip's recommendation was for Reid to set the default himself (in ~/.pydistutils.cfg) so that easy_install puts the scripts on his PATH. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006352.html http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006356.html *Sample test data and recurrence* A few weeks ago, Jeffrey questioned the makeup of the 3k sample calendar, noting that the balance was off (too many recurring events vs non recurring events). Dan suggested that Jeffrey was reversing the count of recurring and non-recurring events. Jeffrey acknowledged Dan's rightness, and noted that the current balance is reasonable. [311 recurring events that each recur 9 times (311 x 9 = 2799) and 2689 non-recurring events.] http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006280.html *Ubuntu Dapper Drake Upgrade* Heikki noted that we'll be upgrading from Ubuntu Breezy Badger to Dapper Drake, and we expect the upgrade to be fairly seamless. Use the Synaptic package manager for one click upgrade. Machines to be updated: qalinux (p_linux), alanui, maunaloa, linuxdev1. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006342.html CATS 0.2 Test Framework ----------------------- *New test framework output* Dan explained that we are getting close to the new test framework switchover (CATS 0.2). The test output will be noticeably different -- Dan included example output and asked for feedback on the format. He also linked to CATS documentation. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006319.html Brian Moseley suggested more concise output as a summary for easier scanning, and gave an example. Andi liked Brian's example output. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006320.html Mikeal explained that the example output gives the detailed information of the one failure, with verbose information about what failed. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006328.html Brian noted that there is a difference between summary info and detailed trace info used to track down a particular problem -- at the console he's looking for summary info and a test-author-provided meaningful message about any failed test as a starting point for tracking it down. He'd rather look at detailed trace info in a log. Also, the sample output is very noisy, he'd rather see more use of whitespace instead of lots of :: ** etc as delimiters. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006329.html http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006333.html Mikeal explained that in CATS 0.2, the log output and stdout are the same, the new framework (OAF) will allow for different output streams and a greater degree of customization. Even in CATS 0.2 we have debug and masking settings to hide/show more or less information -- he's looking for the right defaults. In the meantime, if the output only provides a summary, the tests would have to be run again for failures. He agreed that a test author provided message is valuable, explaining that we don't have as many comment strings in reports as we'd like because the feature is new and the focus has been on getting the framework out. Mikeal explained that the information displayed is all meaningful to the failure (with the exception of the timing information that Brian pointed out), but that perhaps the output format could be improved. Mikeal noted that the end suite summary Brian requested can be printed at the end for CATS 0.2, and in CATS 0.3 we can have the summary output printed in real time. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006330.html http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006337.html Andi suggested trimming some information, replacing "***" with whitespace, etc. and leaving stack traces. Mikeal agreed with some of the suggestions, but pointed out that delimiters are needed in some cases for ease of parsing, and a few other nits. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006332.html Grant pointed out that one of the nits, an increase in processing time to pretty up an output string, is a trivial increase when measured. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006334.html *Cats 0.2 and i18n* Brian Kirsch asked if i18n requirements were being met by the new framework. In particular he asked about wrapping all displayable strings with uw() from the i18n.tests package -- this adds unicode characters to the string, and helped find many i18n problems. The ability to run in different locales and timezones is also important. A different locale/timezone can cause expected output to change, including first day of the week in a calendar, menu UI labels, auto generated collection names, etc. Most i18n work will be completed in the alpha4 timeframe; the testing framework is a key to preventing regressions. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006321.html Dan replied that he did migrate the uw() and other changes. He's pushing to move to the new framework to avoid maintaining two sets of tests. The new framework mainly introduces changes to how tests are run and logged, with little change to the function of the tests themselves. Dan's first priority is to complete the migration, then he can take new i18n requirements. Brian agreed with the priorities, and will do a review to make sure all of the new i18n work got ported. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006324.html Dev projects and design discussions ----------------------------------- *External Information Model* Morgen and Phillip have been discussing an intermediate data representation layer and API for Chandler: the External Information Model. Inbound and outbound items will pass through these APIs when being shared to a server or dumped/reloaded from disk. The layer isolates parcels from external serialization formats, and eliminates the need for the dump/reload format to be the same as the sharing format. This API is also a step towards solving the schema evolution problem. When evaluating sharing formats, we can look at how they are translated to/from this intermediate form. (Further discussion about this work on the cosmo-dev list). http://wiki.osafoundation.org/bin/view/Projects/ExternalInformationModel http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006322.html *Bridging the gap - email options* Sheila kicked off a conversation to discuss options for "bridging the gap" between a user's email client and Chandler, assuming that we won't get users to leave their email client during the beta/1.0 timeframe. She's looking for new creative solutions as well as technical elaboration on the ideas floated so far. The full conversation is happening on the design list (as it spans several groups) even though they are looking for a fairly technical conversation. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006344.html *Modeless dialogs and commands* John asked: What commands should be active when a modeless dialog is on top? Only commands relevant to the dialog (cut/copy/paste)? John suggests it would be most convenient to make all of the commands active generally, but that may require a modeless dialog to reflect changes from some command selected while it is frontmost. Grant pointed out that active commands can lead to situations where menu commands behave in unexpected ways -- more configurations of the app's global state for the menu/event code. Morgen added that the modeless dialogs here are the publish/subscribe dialogs. He noted that he didn't see any problems with the subscribe dialog, but that the user should be prevented from publishing a collection while that same collection is being published in another dialog (a use case that might come up when we allow publishing to mulitple servers). We should also prevent the user from deleting a collection while it is being published. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006297.html Mimi suggested that we could keep things simple and make the publish/subscribe dialogs modal, unless there was a workflow reason to keep the commands active. One workflow issue: users may launch the share/publish dialog before creating and selecting a new collection. We could add a pull-down to the publish dialog so that the users could select a collection (new or otherwise) after launching the dialog. Morgen, John and Reid would prefer to keep the dialogs modeless -- we've done the hard work already. Morgen suggests a pulldown listing the collections wouldn't be difficult. "New collection" as an option might not make sense -- no opportunity to name the collection leaving it named "untitled". http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006305.html Intern and SoC projects ----------------------- *IMAP server parcel* Grant explained that IMAP has specific requirements for UIDs, and thus UUIDs are inappropriate. Mailbox UIDs (UIDVALIDITY values) need to be non-zero 32-bit unsigned values and unique for that path. Most implementations use a timestamp or an increasing sequence of integers. Grant agreed that an initialValue isn't appropriate for validityUID (not the right behavior for deletion and recreation). A random int could theoretically collide. Grant suggests overriding __init__ to make it a computed value (timestamp). uidNext and UIDs have to be 32-bit positive unsigned ints, and must increase monotonically as messages are added to the mailbox. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006273.html Andi suggested hash(UUID()) as an option. Noting that it won't work for the monotonically increasing cases, he worried that using timestamps would introduce bugs. Grant replied that hash(UUID()) doesn't guarantee unique values, which is a problem at least in theory -- IMAP requires that (mailbox path, mailbox UID validity, message UID) uniquely identify a given mailbox. This is used for syncing a given mailbox without re-downloading the entire message list every time. Grant noted that most servers increment an integer to generate UIDs for messages in a mailbox. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006286.html Travis noted that he's incorporated Andi's earlier suggestions, the updated module is available in svn. He'll do a code review after alpha3. Travis explained that he took his solution from the twisted book. Courier-IMAP uses a timestamp. Travis considered combining the two, but went with the timestamp approach, amended to make sure the same uid isn't used twice. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006296.html *Chandler Usage Tracking* Ted reviewed Ashkan's instrumentation project. Ted is interested in the output eventually supporting an "attention recorder". To be able to do this, it would need to be capturing a high level semantic event stream (e.g. "User created a new task <reference to the task>"). Ashkan explained that the code is configuable, and currently reports blockEvents. (Ashkan included example output). Ashkan would like to dump everything notable to a file, available for analysis using post processing scripts. The rationale: simpler implementation and reduced load on Chandler itself; ability to consider data later that wasn't being considered earlier; blockEvent code can evolve independently of instrumentation code; save an immutable/raw record of user activity. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006341.html Meetings and Announcements -------------------------- Apps team meeting: http://wiki.osafoundation.org/bin/view/Journal/AppsMeeting20060713 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
