Re: [Opensync-devel] SCM changes? (was: Re: Fwd: Google plugin for opensync)

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

Hi Daniel,

Thanks for your response!


On Sat, Aug 14, 2010 at 12:22:10PM +1200, Daniel Gollub wrote:
> I guess this would break our test automation we have running currently:
> 
> http://opensync.org/testing/

Interesting items that I didn't realize existed. :-)


> And so far we only have one single svn:externals - and it's just for the cmake 
> modules. Yeah, it's sad that this breaks git and others ... but the cmake-
> modules doesn't change that often. Actually we introduced that due to the fact 
> that cmake and it's modules were still in a very early stage of development. 
> So we had to write a couple of cmake modules by our own to find buliding 
> depencies ... i guess some modules find their way already in recent cmake 
> versions which already packaged in recent distribution. So we could think of 
> getting replacing svn:externals by merging the changed modules - if required. 
> 
> How does that sounds to you?
> You might wanna try this for those repositories you're actively using - e.g. 
> opensync, osynctool(?), google-calendar, file-sync, ... so you can use for 
> those at least a git bridge.

I'm using git already, and have a git-svn clone of the cmake modules as
well, using git submodules to handle it.  It is total hackery and a
pain in the backside, but it works, and I can use git instead of svn. :-)

I'd only want to remove the externals if we were going to include the plugins
in the opensync tree.  This way the cmake-modules would already exist,
could be easily shared, and no externals would be needed.

But with separate svn trees for each plugin, it makes sense to share the
cmake modules too.


> Regarding moving all plugins into one repo ...
> 
> 
> The Distribution packager might not be happy about that ...
> Since this would be heavy packaging change.

I'd be interested in seeing things made easier for the packagers.
It should be possible to just change the svn checkout command,
and cd opensync/plugins/<myplugin> and do the same thing as before.



> Another problem might be the difference licenses.
> 
> libopensync is LGPLv2
> I guess most of the plugins are GPLvX or something else but in most cases not 
> LGPLv ... something which packager might not like as well.

I hadn't thought of that.  I don't think this is a roadblock, but something
that would need to be made clear.  I think each plugin should be individually
compilable, so each plugin could be considered a separate entity.

Sort of "amalgamation."   But I'm not a license lawyer.


> I would still prefer to keep plugins out of the opensync directory.
> Actually i planned to do build testing by ctest and cdash. So i don't have to 
> build-test all plugins by myself. So far only few plugins get build-tested in 
> our cdash/ctest instance. Right now also some magic is required so they get 
> build tasted against latest trunk.

I'm not a ctest / cdash expert, so I don't know how much easier this would
make our lives, but the fact that there is no one maintainer who routinely
builds all the plugins is a problem, in my opinion.  Anyone who is
changing the engine should be pro-actively looking for breakage in the
plugins.

The fact that the plugins are so far behind is due to this disconnect,
in my opinion.  If every change in the engine caused compile breakages
in the plugins, those breakages would get fixed in the course of making
the library changes.  It would happen while the change was fresh in the
engine developer's mind.  It would be less bug prone, and better for users
as well.

I think it should be *optional* to build all the plugins, of course.
But I also think it should be as easy as a cmake option to build all
plugins, and the developer shouldn't have to go hunting for more SVN
repos in order to do it.  Building all plugins should be encouraged
for any engine developer.


> A SCM-repo with libopensync and all plugins 
> might would be a solution. Why not just checking out libopensync and all 
> plugins and write some special make target which jumps to the parent
> directory or special directory where all plugins got checked out?

I do have scripts to do this, somewhat, using git.  It's extra work
to make it happen, and I'd like to share that... the easiest way to
share it seems to be in the opensync build process.


> I guess only few developers going to need to build all plugins at the same 
> time. Those who plan to change/break the API. That shouldn't be the case so 
> often ... right?

In theory.  But like the linux kernel, the more compiler errors normal
developers get, the faster things get fixed, I think.


> But maybe we can provide all this to you some how without changing the entire 
> SCM?

I can hack this up myself, and to some extent, I already have.  But after
all that work, it only improves my system.  Everyone else has to do it
themselves. :-)

- Chris