[Chandler-dev] [Sum] March 27 - April 2

Katie Capps Parlante capps at osafoundation.org
Tue Apr 4 12:04:50 PDT 2006

Build and Release
*Functional tests are now running as part of quick builds*
- Kona (windows), Molokini (os x) and Maunaloa (linux).
Bear will enable notifications after a day or two of green builds. Quick 
builds should be monitored by all Chandler devs for green before and 
after any commits. As we get close to the alpha deadline, Bear will back 
out changes that cause the build to fail.

*Commit policies as we go into alpha2*
- April 13 is feature freeze, 2 weeks before release (April 27)
- All commits after April 13 require peer review and a bug#
- Bug council will retarget bugs or change release date if unrealistic
The goal for the milestone is to have all existing functionality work 
without regressions and the new features to work as designed.

*Checkpoint build for 27 March*
Notice of the build:

Checkpoint build status:

*Bugzilla email feature* Philippe brought up problems with the new 
email-response-to-bugzilla feature, suggesting that the side effects 
(messy hard to read conversations in bugzilla) outweigh the benefits. 
Heikki agreed, noting a technical fix might help -- rejecting messages 
with too much quoting or other abuse. Heikki pointed out that it is cool 
that you can hit reply to the bug email, and that replying in email 
allows you to use the  spell checker.

Andi updated PyLucene (2.0rc1-1) and chandlerdb (0.6-18)

Lisa will do a "geek talk" on Monday, April 10. Topic: distributed 
identity (extranet sharing, single-sign-on, etc).

Apps meeting

Darshana, a student from OSU, is going to be working on a Chandler 
related project (GUI editing tools) as the subject of her Masters 
thesis. She is visiting Monday and Tuesday (April 3-4). Her project:

Robin noted that his new book is out, "wxPython in Action":

Coding and design discussions
Reid asked for a code review for MultiStateButton.

*IEC rename* After wrapping up the vote, Alec renamed 
InclusionExclusionCollection to SmartCollection. (Changes have already 
been committed)

*Testing from PyShell* Phillip advised Reid that he should run his tests 
from PyShell (inside Chandler) this way: (Otherwise "__name__" will be 
set to "__builtin__")

    execfile("whatever.py", {'__name__':'__main__'})


*background sync* Morgen brought up two issues that came up while 
working on background sync, both of which were resolved:

(1) OnIdle can run into merge conflicts when refreshing the main ui 
view. He resolved this by handling the conflicts in OnIdle similarly to 
how it is done in the background sync thread. He explained the 
background syncing procedure:

(2) Some changes happen on the main ui view thread without being 
committed instantly. These changes are not picked up by the sharing view 
(not until they are committed). The decision was to leave this as is. 
Bryan Stearns listed the occasions when the ui view commits:

*Free busy* Jeffrey sent out a nice writeup on Alpha 2 free busy 
implementation details (also captured in the spec):

Sheila asked about recurrence support in alpha 2. Jeffrey explained that 
in the short run the server won't be generating recurrence expansions, 
so the client will have to generate recurrence expansions for some 
arbitrary time period to export to the server's static collection (he 
suggested 6 months).

*Styles* Jed sent the proposal for styles in Chandler (css-like 
mechanism for specifying layout). Jed asked for feedback on which styles 
were important to tackle first. Alec noted that the CSS box model was 
particularly important. He gave a link to a good description 
(http://www.w3.org/TR/REC-CSS2/box.html) and noted that it described the 
different size borders/margins/padding issue  well (Jed mentioned this 
as a common request).

*Collections* Requirements for collections and notifications in 0.7, 
from meetings last month:

*displayName attribute*
Alec asked "is a unified displayName attribute a good thing"?
- all items have an attribute called "displayName"
- we want to index this attribute only for items a user would search

Alec offered two solutions:
- change the repository so PyLucene only indexes certain types of items 
(a particular subclass, perhaps)
- don't use displayName for user-visible items, and don't index 
displayName. Use a new attribute, perhaps "title".

Andi proposed "overriding" the attribute with an indexed attribute. Alec 
thought this solution sounded reasonable.

Andi also noted that Alec's perverse example could actually be 
implemented without having to load all items (PyLucene search for "a", 
filter out all "Notes").

Ted pointed out a second issue: localization. Ted suggested that we want 
a separate "title" attribute. Ted argued this suggests we have two 
classes of attribute here (where the names are currently reversed in 
their meanings):
- title: the "system" name for the item
- displayName: text that is localized, indexed, and presented to the user
Brian Kirsch agreed.

Thread starts here:

*annotating selection*
Alec kicked off a discussion about collections. The summary of this 
conversation became long enough that I'll write it up separately.

More information about the chandler-dev mailing list