Splitting out core and bindings final stages

John (J5) Palmieri johnp at redhat.com
Fri May 5 13:33:14 PDT 2006


On Fri, 2006-05-05 at 15:14 -0400, Havoc Pennington wrote:
> Hi,
> 
> John (J5) Palmieri wrote:
> > 
> > On the dbus irc channel.  Remember the move is only for the bindings
> > right now and not core.
> > 
> 
> I don't see a reason any specific binding _has_ to move to git, the 
> point is that all the bindings can be independently maintained, and just 
> won't be in the main tarball, right?

If someone wants to do the work of splitting it out and keeping history
be my guest though it would be nice to keep them all in the same type of
repo for easy access.  I mainly chose git because cairo is using it,
xorg is moving to it and fd.o has the infrastructure in place.  I am
also finding it very easy to work with for doing the split.  I made a
decision to do this now to stop us from stalling the split (and stalling
a 1.0 release).  All the main contributors to the current bindings set
are comfortable with distributed version control or at least have not
complained and we could sit here for ages arguing over which system is
better but I just want to get work done. 

> i.e. if some specific binding wants to create a directory in cvs or svn 
> and do development there, go nuts... I'd do that if I were maintaining a 
> binding, since I don't hold with these newfangled distributed version 
> control systems.

If they want to I am not going to stop them but I want to move ahead and
get all the bindings out into separate packages.

> BTW is it possible to split out the glib binding? Wasn't I using it in 
> the tests and otherwise entangling it in the main source tree a bit?

Robot101 and robtaylor would have a better answer for this.  I suspect
any tests you use the mainloop for can be converted to use the
read_write_dispatch stuff.  One thing is for sure, we don't want to tie
glib releases to the core.  Perhaps we can keep the mainloop in the core
- I'm not sure.


-- 
John (J5) Palmieri <johnp at redhat.com>



More information about the dbus mailing list