[Pacemaker] [RFC] Splitting cluster.git into separate projects/trees

[Fabio M. Di Nitto]

On Fri, 14 Nov 2008, Andrew Beekhof wrote:

> Top-posting...
>
> #1 is what the current "situation" evolved from so I think its pretty
> clear that despite the best of intentions, it doesn't work out (far
> too easy for cross-dependancies to develop).
>
> #2 - I share chrissie's feelings on this one ;-)
>
> #3 - Thats got my vote - basically what we did with Pacemaker.
>
> The biggest question here is do you want old versions of the split out
> code to be buildable?

I am not 100% sure I understand what you mean..

> Obviously you'd keep the combined repo somewhere, but you may also
> want to be able to build old versions from within the split-out repo.
> If people don't want this, the split out repos _could_ be filtered
> copies (smaller and only contains relevant history).

the only tree that will be authoritative for all versions before the split 
will still be cluster.git. I'd like for all the other trees to preserve 
history for that specific bit. Maybe git allows to purge all unrelated 
commits from the history, but I personally don't know.

Please remember that cluster.git will not die completely. Some RH specific 
bits might still live there in future.

So basically what will happen for #3 is (more or less):

cp -rp cluster.git dlm.git

clone/checkout dlm.git
purge everything unrelated and cleanup all unrelated history/commits
fix build system/Makefile
tag and make first release
remove dlm from cluster.git

(optionally to keep the tree in a decent state while we split)
make it buildable with external entity
tag/release

Fabio


>
>
> On Fri, Nov 14, 2008 at 10:18, Fabio M. Di Nitto <fdinitto at redhat.com> wrote:
>> Hi everybody,
>>
>> as discussed and agreed at the Cluster Summit we need to split our tree
>> to make life easier in the long run (etc. etc.).
>>
>> We need to decide how we want to do it and there are different
>> approaches to that. I was able to think of 3. There might be more and I
>> might not have taken everything into consideration so comments and ideas
>> are welcome.
>>
>> At this point we haven't really settled how many (sub) project will be
>> created out of this split. This will come once we agree how to split.
>>
>> = first approach =
>>
>> We maintain cluster.git as single entity with all source code in one
>> place. We change the build system in such a way each single component
>> can be released standalone (similar to how it was done in the RHEL*
>> branches).
>>
>> Pro:
>>  - preserve current development model.
>>  - allow release of separate tarball for each (sub) project.
>>  - external users don't need to build the whole tree for one (sub)
>> project.
>>
>> Cons:
>>  - move all the burden to the build system (by duplicating tons of
>> stuff, maybe solvable but needs investigation) and release manager.
>>  - tagging for releases will require changes as it's not possible to tag
>> only one (sub) project.
>>
>> = second approach =
>>
>> We maintain cluster.git as single entity. Each (sub) project would
>> become a separate branch.
>>
>> So for example all the gnbd code will be branched into master-gnbd (and
>> so on for all the others).
>>
>> Checking out one specific HEAD will only show the code for that project.
>>
>> Pro:
>>  - cleaner look at the tree.
>>  - partially preserve current development model (still easy to cherry
>> pick changes between branches)
>>  - external users don't need to build the whole tree.
>>
>> Cons:
>>  - more expensive branch management.
>>  - tagging for releases will require small changes.
>>
>> = third approach =
>>
>> We copy cluster.git N times for each (sub) project, clean the master
>> branch to match only that (sub)project.
>>
>> Pro:
>>  - very clean tree from checkout
>>  - each (sub) project is really separated and will have its own
>> identity.
>>  - external users don't need to build the whole tree.
>>  - easier to fine tune access to each single component (for example we
>> can allow user foo to access dlm but not gfs... or whatever combination)
>>
>> Cons:
>>  - more complex process to perform cherry-pick between branches.
>>  - higher risk to commit fixes in one branch and forget in another.
>>  - requires a lot more developer attention.
>>
>> Fabio
>>
>>
>> _______________________________________________
>> Pacemaker mailing list
>> Pacemaker at clusterlabs.org
>> http://list.clusterlabs.org/mailman/listinfo/pacemaker
>>
>
> _______________________________________________
> Pacemaker mailing list
> Pacemaker at clusterlabs.org
> http://list.clusterlabs.org/mailman/listinfo/pacemaker
>


--
I'm going to make him an offer he can't refuse.