Having a Tier 0 for cmake and git submodules

[David Faure]

On Sunday 10 November 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'm very much reminded of kde-common/admin which was an external in all kde 
modules in kde3 times. Which is both good and bad :-)

Good = same way to avoid a dependency just for the buildsystem, bad = makes a 
few actions as a developer more complex, like as you mentionned, having to 
update sha1s manually, in the case of git.

Actually, I just realized that the same solution (to the same problem) is used 
in KDSoap (https://github.com/KDAB/KDSoap.git) with its autogen subdir which 
is a git submodule (to share it with other similar libs). It's actually 
working OK, the only downside is indeed the need to update it manually when 
committing a fix to a buildsystem file.

Where git submodules is better than svn externals is that this won't slow down 
updating one's checkout (a separate command is needed for updating the 
submodule locally). But forgetting to do so isn't a risk, since "git status" 
(and the commented out list in git commit, etc.) reminds you to do so.

If we're really just talking about the 3 cmake files for KDE, updates won't 
actually happen very often.

OK, let's go for it.

Let us NOT call it tier0 though :-)

Note that we still need to ship them as a standalone package too, for people 
who might want to use them - KDE apps outside of git, or Qt apps that want to 
benefit from the rpath stuff that's currently only in there [although that's a 
bug IMHO], etc.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5