[Kde-graphics-devel] kdegraphics git: Summary, part 3. Split vs. monolithic

Marcel Wiesweg marcel.wiesweg at gmx.de
Mon Jan 3 14:52:20 CET 2011


Hi all,

If someone is interested and has a lot of time, the relevant discussion can be 
found here:
http://mail.kde.org/pipermail/kde-scm-interest/2010-September/thread.html#1611
There is a pdf attachment on Tom's initial mail with the KDE sysadmin's 
advice.

I received the following feedback. I allow myself here to cite:

Pau Garcia i Quiles: +/- I don't really care about split or monolithic repos 
for kdegraphics...

Albert Astals Cid: +monolithic: ...because we were supposed to help 
eachother and more people downloading and compiling your code meant more 
people possibly being ready to help. Besides that philosophical rant there's a 
problem with okular, thumbnailers and strigi-anaylxer code that does 
../../libs/mobipocket/mobipocket.cpp (yeah going back in your path outside 
"the project") and will obviously break if you do a split repo.
Besides that philosophical rant there's a problem with okular, thumbnailers 
and strigi-anaylxer code that does ../../libs/mobipocket/mobipocket.cpp...

Aurélien Gâteau: +split That's an interesting issue. I think split repos make 
more sense for kdegraphics because I don't think there is much code moving 
from oneapplication (or libs) to another. It is a different situation than 
what  happens in kdepim for example. I assume it is possible to create a
kdegraphics repository using submodules...

Mathias Soeken: +split I am also for splitting the repos. The structure in 
projects.kde.org does the job fine in my opinon.

Marcus Meissner: +/- I do not particulary care

Kåre Särs: (+)split I do have a hunch that if I'm only interested in a small 
part of the code it is easier to work with the code if I only need to git 
clone a small repo in stead of the whole  thing.

digikam team including myself: +split. Fully agree with the sysadmin's paper 
cited above. We plan to setup a superproject which will reference libkipi etc, 
that would be close to impossible with them hidden in a monolithic repo.
For kdegraphics, such a shell/superproject is probably needed anyway, to solve 
any cross-reference and build issues.

Marcel


More information about the Kde-graphics-devel mailing list