[Cosmo-dev] Sharing work plan

Ted Leung twl at osafoundation.org
Mon Dec 4 16:31:09 PST 2006


So here's a bit more information to chew on...  At the moment, it  
looks like we'll finish all the coding tasks for Cosmo 0.6 by the end  
of the first week of January.   If we have a 1 week stabilization/QA/ 
docs period, we'd be looking at a Cosmo 0.6 release somewhere around  
Jan 12/15.   Of course, these dates may move as we get closer.    
Assuming that we stick to this schedule that would mean that the last  
date for Chandler domain model changes probably ought to be early in  
the first week of January.

If Morgen needs 3 weeks to get done the importer/exporter work, then  
I'd assume that we'd be looking at the first week of January for him  
to start implementing morse code support, so it seems likely that we  
would get very little chance to test Cosmo/Chandler over morse code  
if we stick to a Jan 12/15 release for Cosmo 0.6.  Possible options  
would then be:

1. Branch Cosmo 0.6 but don't release it until we have sufficient  
interop testing with Chandler 0.7a5 - this allows the Cosmo team to  
proceed with feature development for Cosmo 0.7.  The downside of this  
is that we delay the appearance Casual Collaborator features.
2. Issue a Cosmo 0.6 and then issue a Cosmo 0.6.1.  This allows  
Casual Collaborator features to appear, and allows us to update for  
any changes needed for interop testing.   The downside of this is the  
machinery needed to create/test/release 0.6.1 and the effort to  
upgrade osaf.us

I think that it is important to have frequent and regular  
communication amongst all the people working on the sharing format.    
That would include developers for Chandler and Cosmo, as well as  
someone from QA.    We could do this via either a weekly e-mail  
"check in" thread, or a brief (i hope) weekly meeting.

Ted

On Dec 1, 2006, at 2:49 PM, Katie Capps Parlante wrote:

> Morgen and I were discussing the steps for the sharing format  
> implementation in more detail, in particular how they might fit up  
> with the schedule and dependencies. I thought I'd write this up on  
> the Cosmo list to make sure we're all in sync.
>
> He listed out these tasks:
> A. EIM record definitions         (first pass done)
> B. XML serialization              (discussions in progress)
> C. Implement importer/exporter callbacks
>    - records --> items, items --> records
>    - xml --> records, records --> xml
> D. Implement synchronization/conflict detection algorithm
> E. Dump/reload items to files
> F. Hook up to DAV                 (current plan is to skip this step)
> G. Hook up to morse-code
>
> A couple of notes:
> - We have not finalized the domain model on the Chandler side, so  
> we could still need make changes to the EIM record definitions. In  
> particular we'll need to review them for changes made to the  
> recurrence implementation, for dashboard/triage support, for  
> changes made to the mail schema, and for edit/update workflow  
> support. (Edit/update workflow is about knowing who made the last  
> edit, change notifications, etc.)
>
> - Morgen is working on (C: importer/exporter callbacks) now, and  
> expects that to take him ~3 weeks. He'll do a first pass at (E:  
> dump/reload) as a way of testing the importer/exporter callbacks.
>
> - The EIM API (and implementation) to support (C: importer/exporter  
> callbacks) is ready. The EIM API (and implementation) to support  
> (D: sync implementation) is happening in parallel with (C: importer/ 
> exporter callbacks).
>
> - After previous discussions with BCM and Randy, we expect to skip  
> (F: hook up to DAV) altogether and go straight to morse-code. The  
> one worry we have is that we won't be able to hit a January  
> deadline. An alternative is to have EIM-over-DAV up and running as  
> a first stage, in January, as this will be quicker to get up and  
> running. Another alternative is to get Andi to help with the  
> protocol work to bring in the schedule.
>
> Does this fit everyone's expectations? Will making changes to EIM  
> records later in the process have a negative impact on Cosmo  
> scheduling? Any other thoughts/concerns?
>
> Cheers,
> Katie
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev



More information about the cosmo-dev mailing list