[Chandler-dev] [Sum] Nov 6 - 12

Katie Capps Parlante capps at osafoundation.org
Fri Nov 17 14:50:20 PST 2006

Build, Release, QA
Bear spun a checkpoints on Nov 6, 9, and 10. The checkpoint on the 10th 
broke sharing compatibility (see below):

Pieter proposed that we highlight alpha4 instead of 0.6 on the website.
Heikki agreed.

*Road to Alpha4*
Philippe gave some background on why we've been slipping alpha4, and the 
path to get to a release candidate. Philippe explained that our 
objective with alpha4 is to have a stable release for dogfooders, and 
that we have been holding the release until we meet these criteria:
- no alpha4 blocking bugs
- 2 consecutive days without new blocking bugs reported by dogfooders
Blocking bug criteria?
- reproducible crashers
- data loss or loss of major functionality
Please do all dogfooding on alpha4 until we've released!

An additional wrinkle, we decided to go ahead and qualify the release 
against osaf.us (Cosmo 0.5), so this added a bit of time to the release 
as well. Testing against the public server isn't really the best plan 
for the long term, but the server isn't really public yet and the extra 
mileage/testing is useful. Eventually we'll need a separate test server 
(cosmo-test). More details from a recent QA/Build/Release meeting:

*Chandler update breaks compatibility*
An update on the branch and the trunk broke compatibility. Dogfooders 
will need to create new collections on osaf.us. To do so, people will 
need to back up data to *.ics files (using an older Chandler) and 
reimport them (using the new updated Chandler). This process causes some 
loss of data, though it can be mitigated by stamping items as Events. 
Philippe gave detailed instructions, and included the tickets to the new 
office calendar:

*Calendar out of wack*
Morgen explained that the office calendar got out of wack. Due to a 
sequence of events with changes in how UUIDs are generated/handled when 
calendars are imported from *.ics files, and the migration steps taken 
moving from cosmo-demo to osaf.us, we ended up with parallel sets of the 
same items with different UUIDs. Morgen had some fixes to prevent the 
situation from happening again:
- detect importing the same events with a different UUID
- bump the xml version number so that old versions don't cause problems
- deterministically generate UUIDs from non-UUID-like iCal UIDs using an 
md5 hash (e.g. data imported from Outlook). The upshot is that fixing 
the problem necessitated losing backward compatibility w/existing 
shares, new shares needed to be created. Morgen's explanation avec gory 

*SVN instead of builds server for tarballs*
Heikki suggested we use svn for source and binary tarballs, instead of 
placing them on the builds server. Andi was unconvinced that the way we 
do it now is broken.

Bryan, Jeffrey and Grant met up to talk about dashboard work in alpha5.
Jeffrey will focus on occurrences-as-modifications in dashboard 
collections. Grant will work on per-attribute-modifications ("modified" 
occurrences will inherit non-modified attributes from their masters -- 
Bug 6700). Grant will also take on the update workflow architecture and 
domain model.

*Localizable sample text and displayName*
Reid has a task to implement localizable sample text in text fields (Bug 
7292). He asked about 'displayName' going away, as a code comment 
suggested a previous strategy was to use an item's 'displayName' as the 
default sample text. Bryan explained that the repository mechanism to 
generically provide names for any repository item is going away, but 
'displayName' as an attribute on ContentItem is *not* going away. A 
dynamic mechanism for providing localized sample text for the "title" 
field is still needed.

Apps meeting:

Cosmo/Chandler meeting about sharing:

More information about the chandler-dev mailing list