CTDB in master?
obnox at samba.org
Thu Oct 17 01:48:06 MDT 2013
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.
> Also we already some merge commit in the history,
> e.g. a0130c662a40d6951fadae4bd9a6f7c230df05db
> 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.
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...
Size: 215 bytes
Desc: Digital signature
More information about the samba-technical