[Chandler-dev] [Sum] April 17 - 23

Tue Apr 25 15:53:20 PDT 2006

Build and release
-----------------

*Checkpoint build*
This week's checkpoint build was tested on WinXP and Mac. The platforms 
rotate from week to week. Philippe noted that we have a fair number of 
regressions, and that increasing unit and functional test coverage is 
important to reduce the number of regressions.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005819.html

*wx Makefile changes*
Bear made two internal/wx/Makefile changes that affect full builds. (1) 
More generated files are handled in the "clean" target. (2) Some SWIG 
generated files were removed from the SVN repository.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005768.html

*feeds parcel plugin egg*
Continuing the conversation about plugin eggs, Katie and Phillip noted 
that they would rather back out the egg change than disable functional 
tests, and that backing out the change is not a big deal for alpha2.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005779.html

Brian Stearns explained that he's still making changes to CPIA APIs, 
which sometimes causes him to need to make changes to the feeds parcel. 
If a parcel change requires a separate release step, tinderboxes break 
for a while and it stretches and complicates the checkin process.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005778.html

Heikki proposed that we leave the changes in until we observe the 
situation that Brian described (perhaps we won't have API changes that 
require feed parcel edits before alpha2).
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005781.html

The decision was to go with Heikki's proposal. If Brian or others need 
to make an API change that affects the feeds parcel, PJE will back out 
the change.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005827.html

*automating egg parcel updates*
Heikki made a proposal for automating parcel egg updates, where changes 
are made with a single commit. "make install" would automatically build 
the egg and install the egg. If we want to upload/download, Tinderbox 
could upload the eggs and then a normal "make install" could look for a 
download first. Heikki wants to avoid the case where svn would need to 
do an automated checkin to update the egg version number in the Makefile.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005785.html

Phillip responded that this proposal would make it impractical to work 
on a new but unreleased version of a project on the trunk. Phillip had a 
counter proposal: chandler/Makefile would specify version ranges to 
easy_install, and allow easy_install to make the build vs download vs 
install decision. Phillip has details about how this would work. This 
proposal is consistent with the plans he'd worked out with Bear, with 
the one change that easy_install running on tinderbox quick builds would 
be able to automatically build the eggs when needed.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005787.html

*compiler versions*
Heikki explained that traditionally open source projects support/allow a 
wide variety of compilers, to facilitate participation. Some developers 
are using different compilers from the tinderboxes, occasionally seeing 
different results for a handful of bugs. Heikki proposed (1) print 
warnings for potentially incompatible compilers or (2) stop with an 
error if the compiler is different. In either case, allow a STRICT or 
LOOSE override for the alternative behavior. The ensuing discussion 
didn't come to a consensus -- a few rejected the proposal, suggesting we 
clearly document the compilers we support and use autoconf/configure. 
Among those who liked the proposal, some argued that a strict default 
makes it easier to avoid mistakes, and others argued that a loose 
default makes it easier for community members who won't be using the 
same compiler as tinderbox.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005792.html

*wx build/merge/test*
Robin shared some thoughts on improving the wx build setup, leveraging 
svn's strengths. He proposed a few extra wx branches in addition to the 
trunk. A "stock_wx" branch could be an exact copy of wx's CVS, updated 
automatically and used as the source of merges. "osaf_wx" could be 
branched off of this, with osaf's customizations. Anyone doing day to 
day wx development (John, Robin, Reid) would use the osaf_wx branch. 
Tboxen would watch this branch, and "stock_wx" could be automatically 
merged in. The wx on the trunk would be a periodic snapshot of osaf_wx. 
Heikki and Robin also discussed having tboxen for private developer 
branches or build robots that test patches before commit to avoid 
breakage; Heikki thought this might be overkill. Andi mentioned that it 
might be useful given the pressure not to break tboxen. Robin noted a 
problem: how to coordinate changes required in Chandler code? Heikki 
pointed out that after some changes planned for alpha3, the branch 
tboxen will flag wx changes that break chandler functional tests. When 
developers commit changes on the trunk, they can commit chandler changes 
at the same time. Robin noted that changes in osaf_wx that make it back 
into widgets would require some by hand merges.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005820.html

Heikki noted that the wx machinery is complex enough that we might want 
to create a completely new svn repository for wx, which would look like 
just another external lib to Chandler. Andi and Alec agree with this 
plan, noting that it is similar to how PyICU and PyLucene are handled. 
Alec noted that as long as (1) unit and functional tests on wx changes 
are run just before creating a tarball and (2) tarballs are only created 
when the tree is already green, then we should avoid bad wx landings. 
This allows those who are working on wx day to day to make independent 
decisions: when to leave the wx tree broken for a short spell, how to 
branch, etc.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005823.html

Coding and design discussions
-----------------------------

*unified displayName*
Continuing the discussion "is a unified display name a good thing?", 
Katie and Alec both made distinctions between user data (instances of 
ContentItem) and everything else (domain model schema, blocks, 
timezones, preferences, etc). User data should be indexed and not 
localized. Domain model schema names show up in the ui (column headers, 
attribute labels), thus need to be localized (but not indexed). Alec 
observed that this information might logically belong to the view, but 
saw no practical way to make that happen. Alec argued for continuing to 
use the "displayName" override, where ContentItem has its own 
displayName that is indexed, leaving all other displayNames localizable 
and not indexed. Katie argued for essentially the same distinctions, 
should we introduce a "title" attribute instead of using the override.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005766.html
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005784.html

Ted wrote up the working agreement from the platform meeting (Alec 
joined the meeting): create a "title" attribute on ContentItem, which is 
indexed and not localized. "displayName" requires more thought. If we 
store localized versions of strings in attributes like displayName, we 
can't switch locales dynamically (without work to address this). Not for 
alpha2, but we might (1) rip out displayName altogether and use context 
specific attributes (2) introduce a different attribute and place that 
attribute only on items that show through to the ui. Ted was going to 
look at adding a "title" attribute to ContentItem for alpha2. (Ted later 
decided *not* to do this for alpha2).
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005786.html

Brian Kirsch likes the idea of removing displayName and replacing it 
with context specific display attributes. He argued that a generic 
attribute like displayName is very hard to localize, putting a big 
burden on the localizer to understand when and how it is used. 
Conversely, if we have displayNames for a bunch of things that are not 
needed, we bloat the localization templates and make maintaining them 
harder for no good reason. Brian also noted the distinction that Katie 
and Alec referred to, calling the categories "Meta data" and "user 
data". Brian argued that "Meta data" needs to be refreshable without 
altering "user data". This distinction is useful when migrating between 
releases, loading a new localization, etc.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005810.html

*schema.Text vs schema.Lob*
Grant pointed out that Ted's problem with changing the body attribute to 
schema.Text was due to the bodyString calculated attribute, not that 
schema.Text is not indexable. bodyString should be removed, all uses 
replaced with body.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005773.html

*0.7 i18n roadmap*
Brian outlined the i18n proposal for 0.7: enable plausible localizations 
of Western languages, with a French localization as an example. The main 
new infrastructure feature is Python egg support for localized resources 
-- localized meta data can ship with an egg. Brian also listed other 
related changes (displayName cleanup, body attribute type change, Byte 
type deprecation, cpia-ified dialogs, wx .po files), and included the 
list of open i18n tasks in bugzilla.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005811.html

*SmartCollections and the repository viewer*
The repository viewer doesn't understand the structure of 
SmartCollections. Alec is working on a fix, expected to land in a week 
or two.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005814.html

*sizing issues on the mac*
OnSize event propagation is different on Mac than on the other 
platforms. Grant asked if this is a bug, and suggested this may be the 
cause of the table sizing mac problem. Robin responded that in general 
the wxWidgets group usually considers this type of issue a platform 
difference that must be lived with.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005818.html

*0.7alpha2 backwards compatibility with 0.6 shared collections*
Morgen noted that due to a few small workarounds, we have compatibility 
between 0.7alpha2 and 0.6 shared collections. The changes that required 
workarounds: (1) non-naive datetimes (2) body attribute change (3) 
InclusionExclusionCollection to SmartCollection. Morgen has documented 
the workarounds in the code. This approach is not our long term 
approach, however. We're tackling the sharing format issue for alpha3, 
and will remove the workarounds when we implement the longer term solution.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005826.html

*mine/not mine*
Alec described a bug fix that alters the meaning of mine/not mine. 
Before the change, all items were "mine" and in the "all" collection 
unless they were explicitly labeled as "not mine". The logic was 
reversed, items and collections are not in "mine" unless: (1) the item's 
collection is added to "mine.sources" using "addSource()" (2) the item 
is explicitly added to the "all" collection's inclusions using "add()". 
There is no explicit "not mine" collection, and if an item is in any 
"mine" collection it is considered "mine", consistent with PPD's 
requirements. Alec pointed out that this behavior is now more generally 
consistent with Mimi's idea of "spheres". Alec also explains how to test 
for "mine" or "not mine".
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005826.html

Announcements and meetings
--------------------------

*Google summer of code*
Google has announced another summer of code program for 2006. To 
participate, we need projects and mentors. Students begin signing up 
between May 1 and May 8. Send email to Ted (or the list) if you want to 
volunteer. Volunteers will need to work with Ted on the specifics of the 
projects. Many more details and links in Ted's writeup. wxWidgets is 
participating in the program and Robin signed up to be a mentor.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005812.html

Bryan updated the wiki with notes from Monday's Item Notification code 
review.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005782.html

OSCON early registration now open
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005788.html

Apps team meeting
http://lists.osafoundation.org/pipermail/chandler-dev/2006-April/005802.html