CTDB in master?

[Michael Adam]

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.

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.

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.

Cheers - Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 215 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20131017/b449e192/attachment.pgp>