[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