RFC: spinning off base libraries

[Michael Adam]

Hi Simo,

I had proposed this at the team meeting at sambaXP.
And it was rejected, mostly due to the additional amount of
work required and the lack of real benefits.

Now that you have elaborated and emphasized some of the benefits,
I am interested in hearing what Tridge, Jerry and the other
"objectors" say...

I myself am currently undecided, since I see that apart from the
usefulness, it really is an additional workload that has to be done.
And it I think it is a bigger task than it might seem.
If someone can take care of maintaining these libs separately,
I am of course in favour of the spin-offs.

One problem is that libreplace is not quite complete yet.
E.g., it implements different sets of functions on different
platforms. That would have to be fixed/completed first, right?

Cheers - Michael

simo wrote:
> There are a few base libraries that I would really like for us to spin
> off to their repositories and have their own releases.
> 
> I am referring in particular to:
> libreplace (it's a dependency for the other ones)
> talloc
> tdb
> libevents
> later also libldb
> 
> The reasons are many.
> 
> 1. packaging
> 
> We use these libraries in both samba3 and samba4 and there is growing
> interest in using them outside of them (tdb has been for some time).
> While in 3.2 we allow to build them separately we still (in Fedora for
> example) have to respin everything on any change even unrelated to these
> libraries, breaking them out with their own tar.gz release would allow
> distributions to update only the packages that need to, without building
> the whole thing again.
> 
> 2. stabilization
> 
> By making separate trees we will make it more clear to every developer
> that any change will result in the need of a new release, this tend to
> encourage keeping changes to a minimum and make sure API/ABI is not
> compromised, it also avoid taking the route of quick hacks, and
> reintroduce dependencies on the rest of the samba code base.
> 
> 3. sharing
> 
> Because these libraries are in the samba tree and change at will, it is
> diffuclt for external projects to rely on them without copying their
> tree and basically forking them. By making these projects slightly more
> automonous with their own repository, we encourage sharing and
> contribution to the single libraries. We also can make a better job of
> versioning and release with the ability to control when to change soname
> or such every time we end up with the need to break the ABI.
> 
> 
> Who take care of this code?
> The Samba Team as usual, but going on with the project we might find
> even new maintainers for specific libraries and have someone take over
> release management duties for just one or more of them. This also would
> be beneficial in sharing the load of managing, testing, and releasing
> that code.
> I think the small burden of having to check out multiple trees (and that
> might not even be necessary with git submodules) would be largely paid
> back by the benefits of spinning these libraries off.
> 
> I would, of course, volunteer to help spinning them off.
> 
> 
> How can we make it easy for people to keep building samba from a single
> tarball?
> It's not difficult to release a tarball that includes also all the spun
> off libraries, it would contain the sources of samba and all libraries
> and a very simple Makefile that builds/installs all dependencies and
> finally samba with a single "make" command.
> 
> 
> I'd welcome comments on the proposal, so that we can start working
> toward this goal.
> 
> Simo.

-- 
Michael Adam <ma at sernet.de>  <obnox at samba.org>
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.SerNet.DE, mailto: Info @ SerNet.DE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20080616/6a1c868f/attachment.bin