On 12.01.11 13:37:19, Marcel Wiesweg 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
Then why split at all? All your points above suggest that having a split repository has no benefit for you and its unclear wether it'll ever have any benefit. If you leave it up to each submodule maintainer to decide wether its submodule should be buildable standalone or not, then you may end up with some never building standalone. Which means people always need the umbrella-module. Having said that, if someone in your team wants to setup a repository that has a shell script to pull the other ones in, there's no technical reason speaking against that (AFAIK). > 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? Well, with a split-repo approach each of them should get a separate repository with its own history. Unless they've been completely deleted from svn, the folders are still somewhere, so someone would need to take care of them being in kdegraphics when writing svn->git conversion rules for them. > 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. I personally would group them into something like kdegraphics-strigi or so. While one can split them up, they're sufficiently related I guess that it may become a burden. Think about API-changes in strigi and other such things that require changes across all of them. Andreas -- You will be held hostage by a radical group. _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
