Re: [Opensync-devel] Getting things back on track

[Chris F. <cd...@fo...>]

On Mon, Oct 19, 2009 at 06:39:01PM +0200, Daniel Gollub wrote:
> On Monday 19 October 2009 06:05:12 pm Henrik /KaarPoSoft wrote:
> > 
> > ----- oOo -----
> > 
> > So, here is a proposal:
> > 
> > Let's create a new project (called newSyncML? OpenSyncML? ???)
> [...]
> 
> I thought also about starting with OpenSync from scratch or so ... but this 
> would cause even more confusion and damage i guess - and it would also take 
> lots of time to get the same (basic) functionality we have today.

I agree with Daniel.

Starting over is why 0.4x is taking so long.  And that kind of "starting over"
was more of an API and refactoring in order to add new things like
capabilities, etc.  Starting from scratch is just that much worse of an idea,
in my opinion.

Writing a truly generic syncing library takes a lot of forethought, and
OpenSync has done the work to get this far.  Let's not abandon ship now.

In my opinion, one thing that could be done to speed up OpenSync development
is to change the release cycle, and the release priorities.  API backward
compatibility has been a set of handcuffs hindering progress.  When people
saw that 0.22 was undergoing a rewrite, and when they saw how long it
was starting to take, they (including me) put it on the mental back burner
until it was ready.  This mentality robbed OpenSync of input, and it left
responsibility for progress on the "other guy's" shoulders.

A radical idea: the day that 0.4x is released (which should be today),
it should be abandoned, and 0.5x should start.  0.40 would == 0.50.
But the goal of 0.5x would be to remain release-ready stable at all times.
It should be possible to checkout the latest SVN of the 0.5x tree,
and all documentation and functionality should be ready to go into
any distro.  Simple tarball releases of 0.50, 0.51, 0.52, etc would
happen automatically, almost scripted, every month.

The only guarantee that 0.5x would NOT make is API stability.  If an API
change breaks existing code, make note of it, bump the lib.so and the
include directory version numbers, and release right away, with a
porting note in the release announcement.

This breaks the work of staying current into small chunks.

Leave API stability for the 1.0 release.

We never want to get into this situation again, where people are clinging
to 0.22 because it is the only stable API.  Get rid of the stable API
promise until we're ready to actually deliver it.

- Chris


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.