ntdb in Samba?

Michael Adam obnox at samba.org
Sun Mar 15 17:32:46 MDT 2015

On 2015-03-14 at 15:07 +0100, Volker Lendecke wrote:
> On Sat, Mar 14, 2015 at 01:14:31PM +0100, Michael Adam wrote:
> > On 2015-03-13 at 20:51 +0100, Volker Lendecke wrote:
> > > On Fri, Mar 13, 2015 at 06:01:42PM +0100, Michael Adam wrote:
> > > > Excellent idea.
> > > > 
> > > > I also find it regrettable that the proposed git tree has been
> > > > withdrawn so fast..
> > > 
> > > My point is that we need a better communication strategy about which
> > > pieces of Samba we want to take the liberty to change without notice
> > > and which pieces we stick to.
> > 
> > That is easy (and has been stated several times):
> > All components that are not explicitly flagged as
> > published APIs/libraries can be changed by us at will.
> > External consumers will have to adapt.
> So every SAMBA_LIBRARY without private_library=True and with
> a vnum= is a published API? I don't think we can make
> promises for things like samba-util, tevent-util or even
> samba-hostconfig. 

Well, a library not marked private and carrying a vnum can
still be changed at will. It does not have a release cycle of
its own. But we should bump vnums before doing a samba
release. I think this is the only promise we give when giving
a library a vnum. This gives potential external consumers an
easy way to tell when they need to adapt. That's all. Of
course we also have the liberty to remove a versioned internal
library that we don't need any more.

This is fundamentally different from the case of _separately_
published and released APIs like talloc and tdb and so on. As
Ronnie wrote, these could (and maybe should) be maintained in
separate repositories.

Which of our samba-libraries have a vnum (and why) and which
should be marked privated instead is different question. And
we should probably audit the wscripts in that respect. I am
not aware of a good reason for samba-util or tevent-util to
carry a vnum...

And again, all this imposes zero requirements upon us with
respect to unpushed patchsets that are intended for master,
which do not qualify as external consumers for me.

Cheers - Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150316/116d72a4/attachment.pgp>

More information about the samba-technical mailing list