[Chandler-dev] [Sum] July 10 - 16
Katie Capps Parlante
capps at osafoundation.org
Sun Jul 23 16:25:47 PDT 2006
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:
Friday, July 14 checkpoint report (release candidate):
*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.
*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.
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.
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.
*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
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.
*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
*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.
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.
Brian Moseley suggested more concise output as a summary for easier
scanning, and gave an example. Andi liked Brian's example output.
Mikeal explained that the example output gives the detailed information
of the one failure, with verbose information about what failed.
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.
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.
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.
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.
*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.
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.
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).
*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.
*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.
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
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
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.
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.
*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.
Meetings and Announcements
Apps team meeting:
More information about the chandler-dev