[Chandler-dev] Checking background sync into the trunk [Poll]

Katie Capps Parlante capps at osafoundation.org
Tue Jun 6 17:31:03 PDT 2006


I'm in favor of #1
    + background sync is currently our highest priority for alpha3
    + we've found so far that finding the bugs and making reproducible 
test cases to be the time consuming part, and fixing bugs goes more 
quickly, so I'd like to see us invest more time as a team in finding bugs
    + if we shake out problems earlier we can make a better assessment 
for the schedule, which helps with other planning decisions

Morgen, could you elaborate on the consequences of stamping/sharing not 
working correctly in the interim? Does it fail gracefully?

Cheers,
Katie

Morgen Sagen wrote:
> I still have one or two loose ends to wrap up, but we're getting close 
> to landing the background sync feature to the trunk.  The biggest issue 
> we know about is stamping/unstamping a shared item is not yet supported. 
> One reason for this is background sync makes heavy use of the 
> repository's view-merging functionality, and has pushed view-merging 
> more than any previous code.  View-merging has changed enough that we 
> would like it to be exercised and stabilized before adding features to 
> it (including stamping support).   Also, since stamping may be 
> implemented via annotations in the future, that would obsolete any 
> view-merging code Andi would have to write to support stamping now.
> 
> So the choices are:
> 
> 1) Check bgsync code into the trunk now, do without stamping of shared 
> items for some amount of time, but get the rest of view-merging solid 
> first.
> 
> 2) Keep the bgsync branch separate from the trunk until we can add 
> stamping support to the view-merging code, which means view-merging 
> won't be fully exercised before we add further complexity, and the 
> continuing head-aches of maintaining a branch (which Andi has been 
> mostly doing -- thanks Andi!)
> 
> I vote for #1, but I would like to get feedback on how painful it will 
> be for people if shared-item-stamping isn't supported for a while.  "A 
> while" is a function of how much work it first takes to stabilize 
> sharing once we land the background sync changes.  After that, 
> supporting stamping sounds like it would be on the order of 2 to 3 weeks.
> 
> ~morgen
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> 
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev



More information about the chandler-dev mailing list