Proposal: Split libtalloc, libtdb, libtevent and libldb into a separate upstream project

[Stefan (metze) Metzmacher]

Am 10.01.2011 13:26, schrieb Stephen Gallagher:
> On 01/07/2011 04:58 PM, Andrew Bartlett wrote:
>> We can of course discuss releasing these packages more often, but it's
>> actually the devolution of the maintainer-ship that has made this more
>> difficult.  When I last discussed this with Jelmer (Samba4 release
>> manager), he didn't feel comfortable blessing a tdb release for each
>> Samba4 alpha release, as he isn't the tdb maintainer (that's rusty's
>> job).  But at the same time, we have enough trouble getting Samba alpha
>> releases made, that he didn't fancy getting the prerequisite packages
>> released by their maintainers first.  The same would apply for ldb and
>> talloc etc. 
> 
>> Finally, you suggest that the SSSD team could assist with ldb
>> development.  We would of course welcome your assistance.  We also
>> appreciate you raising this issue, it is important to understand what
>> our library users need, and hope we can find a mutually satisfactory
>> improvement to our processes. 
> 
> 
> Sorry, I disappeared for the weekend before replying to my original
> email with a summary of some of the topics that were discussed in
> #samba-technical on Friday as well.
> 
> First, a little bit of background. Simo and I had been working on Friday
> to identify the source of a serious performance bug in SSSD. While we
> were profiling the code, it became apparent that we were seeing very
> slow performance because all of the libtdb actions inside libldb were
> performing a full traverse instead of an indexed search. Simo told me
> that newer versions of libldb have support for a debugging mode that
> will tell you when a command is going to run a search without indexing,
> so we were trying to get that compiled to use.
> 
> The difficulties we had with getting these new versions in place (which
> we never managed as of Friday) brought up a discussion about how all of
> these libraries have seen ample development in the last year, but have
> still not seen a public tarball release in a very long time. Libldb in
> particular has NEVER had an independent upstream tarball release. We've
> had to extract it from the public alpha releases of Samba 4 in order to
> use it with SSSD. Currently, the most recent version of libldb available
> in a released tarball is 0.9.10, while the upstream version is 0.9.22.
> 
> This brought me to suggest that perhaps we should start working towards
> making these libraries more readily available. My original thought was
> that, since these libraries now form the core of more than one large
> project, it would be mutually beneficial for us to turn them into their
> own upstreams.
> 
> We had a long discussion in #samba-technical on Friday where we weighed
> the pros and cons of this, as well as some related matters: the bundling
> of dependent libraries in the Samba tarballs and more regular releases
> of these libraries. The individuals most involved in this discussion
> were jelmer, vl and metze, along with Simo and myself.
> 
> At the conclusion of the discussion, I believe we came up with a mutual
> agreement that the best way forwards would be this:
> 
> 
> 1) Libtalloc, libtdb, libtevent and libldb should see upstream tarball
> releases on a much faster basis. I will be discussing with my management
> at Red Hat whether I can volunteer to take this responsibility on.
> 
> 2) As an addendum to the above, we should look into automating the
> release process for these libraries, based on changes to the version
> variable in the wscript file.
> 
> 3) Include git tags for each of these library releases, instead of only
> for samba releases.

Autogeneration of the tags and release tarballs would be the simplest
approach.

The only need to think about how to generat gpg checksums.
Or we just generate emails to a release manager to let him do the final
sign off.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20110110/a5ed5a77/attachment.pgp>