CTDB in master?

[Amitay Isaacs]

On Thu, Oct 17, 2013 at 6:48 PM, Michael Adam <obnox at samba.org> wrote:

> On 2013-10-17 at 07:28 +0200, Stefan (metze) Metzmacher wrote:
> > Am 15.10.2013 16:15, schrieb Simo:
> > > As much as I normally hate merges, I think this is one of those rare
> > > cases where a merge is the only thing that makes sense, even after a
> bit
> > > of history rewrite due to moving to a subdir.
> > >
> > > It wouldn't make sense to rebase everything on top as older commits
> > > would have no working tests anyway so it is better to do bisects only
> >
> > That's exactly why I used a merge.
>
> Ok.
>
> > Also we already some merge commit in the history,
> > e.g. a0130c662a40d6951fadae4bd9a6f7c230df05db
>
> Yeah. :-}
>
> > Git merges are a bit like talloc_reference(), you should try hard to
> > avoid them but sometimes they're useful.
>
> ;-)
>
> > Also note 'git rebase -p' tries to recreate merge commits.
>
> Alright, I guess that's ok.
>
> What we really need to agree on and discuss (and especially
> Amitay's voice is needed here) is how we will do CTDB releases
> in the future:
>
> - Will we just release ctdb as a component of samba
>   starting with 4.2 and drop the independent version numbering?
>
> - Or will we do it as with talloc, tdb and friends, i.e.
>   independent releases.
>

Currently ctdb does not behave like other libraries (talloc, tdb, ...).
There is no libctdb implementation which samba can build against.  Samba
directly includes the private ctdb headers and re-implements most of the
protocol. Till we have a libctdb implementation that is complete, and Samba
code in  ctdbd_conn/dbwrap_ctdb is using libctdb, there is no point in
doing separate CTDB releases.  That just creates confusion -- which CTDB
version to be used with which Samba version.

One could argue that the reason for putting CTDB into the samba
> repo, namely the fact that ctdb is actually not ready to be a
> separate project yet, implies that ctdb versioning and releases
> should be aligned with samba. I am not quite certain yet.
>

I agree. At least till we have a working libctdb, we should not do separate
releases.


> Anyways we need to tell how to treat stabilizing ctdb
> versions and make sure the file server part can still be
> run with ctdb version other than the shipped one.
>

In future, we would be able to separate CTDB as a standalone project with
it's own versioning if we need faster release cycles than Samba.  By then
we should be able to mix versions of Samba/CTDB as CTDB features will be
decided at runtime and we shouldn't need to restrict features at
configure/compile time.


>
> Cheers - Michael
>

Amitay.