CTDB in master?
amitay at samba.org
Wed Oct 30 17:52:43 MDT 2013
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
> > > 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.
> > 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
> 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
> Cheers - Michael
More information about the samba-technical