Having a Tier 0 for cmake and git submodules

[Michael Pyne]

On Sun, November 10, 2013 17:57:00 Kevin Ottens wrote:
> Now back to the submodules sha-1 update... The only thing I see to easily
> overcome that for our developers, is to have a hook, which would update the
> submodules for all the frameworks every time someone pushes in the tier 0
> repository. Is it something the sysadmins would agree to have on the server?
> 
> Any opinions or thoughts on that?

I would highly recommend doing something similar to what was done for strigi 
when it was split into 5 git modules.

There was something like

strigi/strigiclient
strigi/libstreams
strigi/libstreamanalyzer
strigi/strigiutils
strigi/strigidaemon

These are all separate, independently-buildable/packageable software modules. 
These are used directly by kdesrc-build (which doesn't support git-submodules) 
and also by the build.kde.org CI infrastructure.

As a separate convenience for users building manually, from READMEs, etc., 
there is a separate strigi/strigi supermodule.

If you clone that module you'll see that it has directories for each of the 5 
strigi submodules, but that they're all empty. In other words, it's a shell 
already laid out for the user, who needs only to run "git submodule update" to 
get a full strigi checkout, which can be built all-at-once by the 
supermodule's shell CMakeLists.txt. Indeed, the CMakeLists.txt could even be 
configured to automatically handle the 'git submodule update' if desired. We 
could also do the tarball release from here in theory (seems to be what we do 
for strigi), though I'd recommend tarballs from the underlying submodules 
instead (which also eliminates the need for git archive-all).

Splitting it up this way, we can emply proper inter-module dependencies (such 
as for distributions who track development from git, kdesrc-build, 
build.kde.org) without the requirement to write new code to support git-
submodule just for this, while still allowing people who don't need to 
use/support such tools to get the full benefit of git-submodule doing the work 
for them.

It also shouldn't add much (I doubt any!) work to the existing new code that 
would have to be written for a new git-submodule-using repository. The one 
concern is making sure that new code gets committed to the underlying 
submodule, but my understanding of git-submodule is that this would work 
correctly anyways (and it's an issue using submodules either way, whether we 
adopt my proposal or not).

In short, I don't mind giving third-parties a way to quickly and easily grab 
"tier0" without needing kdesrc-build (or anything other than git and CMake). 
We should even package convenience tier0 releases in tarball form. But we 
shouldn't reconfigure our git repositories or release/packaging processes to 
do this (at least to the extent of requiring one or both of git-submodule and 
source code updates during CMake). Instead we should simply make a separate 
git super-repo intended for that third-party usage and retain our existing 
separate repos for the benefit of our current devs, infrastructure, and 
interested third-parties/distribution packagers.

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20131110/ae8285d3/attachment.sig>