[Kde-scm-interest] Re: kdegraphics - a few technical questions

[Ian Monroe]

On Wed, Jan 12, 2011 at 06:37, Marcel Wiesweg <marcel.wiesweg at gmx.de> wrote:
> Hi,
>
> we are now internally discussing the kdegraphics git move with all interested
> and involved developers.
> Some technical questions that arose, given we take the split repo approach:
>
> 1) Would it be suitable to have a shallow shell / umbrella repository
> including toplevel directory contents glue like CMake files, READMEs or AUTHOR
> files etc., with the submodules' repos copied inside this?
> This would allow to a) dont have to edit CMake files right now to make
> everything compile standalone (would be a hurdle right now, could be achieved
> in the long run)
> b) allow to cope with some cross-submodule source file dependencies for now
> c) strengthen the coherence of the module
> d) may contain a convenience script to pull all repos
> e) leave it as a choice of individual submodules to build standalone, or
> require the umbrella.
> f) if git-submodules or a different approach becomes usable for this purpose
> in the future, use it then

The key is to not make this super-repo a requirement to build
kdegraphics. If you do, then you more-or-less give up one the bigger
advantages of having split modules (making it easy to work on one
project).

So we've been thinking it might be interesting to make a module like
that for kdebindings. Probably not use git submodule, since it seems
awkward, just a small script to clone and update. The key is that we'd
be using some cmake features I just recently learned about. There's a
function called export that lets you use a cmake target from a
separate project. This lets you use dependencies from other modules
without installing that module so it seems well suited for creating
super-repos. (Of course all this might be irrelevant for kdegraphics
if you don't have many interdependencies)

> 2) What happens with apps that have been in kdegraphics but are no more?
> I see katalog, kcoloredit kdvi, kfax, kfaxview, kfract, kghostview, kiconedit,
> kooka, kpaint,kpixmap2bitmap, ksvg, kpovmodeler, kuickshow, kview, pixie,
> ligature, libkscan, libminimagick. A separate repo for each in kde-
> unmaintained, or a "kdegraphics-history" repo?

You can if you want. You have no responsibility here though. They are
still in SVN.

> 3) There are strigi-analyzers and thumbnailers, both consisting of smaller
> submodules and with no explicit maintainer. Would you recommend to keep them
> separate or merge them into a kdegraphics-runtime module? Just an idea, no
> opinion from me here.

What about having strigi-graphics-analyzers and thumbnailers repos?
kdebindings split up, you can see the result here:
https://projects.kde.org/projects/kde/kdebindings
So we spliced and diced quite a bit, but we did keep together the
'kross' modules. They are all pretty small projects with a simple
dependency tree so it just made sense. It sounds like a similar
situation.

Ian