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

[Andreas Pakulat]

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.