On Wed, Jan 12, 2011 at 06:37, Marcel Wiesweg <[email protected]> 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 _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
