[Chandler-dev] [Sum] April 17 - 23
Katie Capps Parlante
capps at osafoundation.org
Tue Apr 25 15:53:20 PDT 2006
Build and release
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.
*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.
*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.
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.
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).
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
*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.
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.
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.
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.
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
Coding and design discussions
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.
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).
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.
*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.
*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.
*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
*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.
*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.
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".
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.
Bryan updated the wiki with notes from Monday's Item Notification code
OSCON early registration now open
Apps team meeting
More information about the chandler-dev