Randa: GIT migration plan for KDE Multimedia
esken at kde.org
Sat May 28 11:08:55 BST 2011
Am Montag, 17. Januar 2011, 01:34:04 schrieb Michael Pyne:
> On Wednesday, January 12, 2011 14:31:12 Ian Monroe wrote:
> > So we should move to Git. Its what folks are doing.
> > What do people think? Luckly Nicolas Alvarez that I have CCed to this
> > email (PovAddict on IRC) would do most of the work involved. There
> > would need to be some cmake-tweaking to make each app build on its
> > own, but it should be pretty straightforward.
> Well, we should go ahead and see if we can get a conclusion to this. I
> personally would probably prefer a non-split repository. However I could
> certainly live with a split one, and to that end I have some ideas of how a
> split repo would be setup:
the discussion of the kdemultimedia GIT migration seems to have subsided in
January because there was no real consensus.
Personally I do not care so much about split/non-split, as it is the
repository maintainers and the distributors that are much more affected. My
assumption is that several distributors would welcome this step as they ship
the KDE MM as separate packages since years (openSUSE, Ubuntu, Mandriva). Not
all do this though, e.g. Fedora if I understand that correctly.
It is time to come to a conclusion. So we should talk in Randa to some of the
guys that are more or less affected, like sebas. I also see Raphael Kubo da
Costa listed with the topic "buildsystem", so lets find him in Randa too. :-)
If reach no final decision we will at least have a "master plan" how to
proceed and when to finish.
> As a reminder, here's the directory layout we need to take care of:
> The easy things are applications: JuK, KMix, Dragon Player.
> On the other hand, KsCD and kio_audiocd are independent, and both use
> and libkcompactdisc. So, I would think that those all go into a
> compactdisc repository. (And by all means, feel free to suggest better
> ffmpegthumbs and mplayerthumbs have similar functions (obvious from the
> Take those and add strigi-analyzer and we have metadata-gathering
> applications. So maybe clump those into kdemultimedia-filemetainfo ?
> From there we can leave all the rest in a "kdemultimedia" base module. I'm
> sure that git supports base modules that are not simply shells around
> submodules (i.e. modules that have files of their own *and* submodules). But
> if git doesn't support that, we can work around it with
> projects.xml+a_build_script and/or CMake magic.
> Thoughts? Any other opinions from KDE Multimedia devs regarding whether to
> split (and if so, how?)
> - Michael Pyne
More information about the kde-multimedia