[Kde-games-devel] Re: Move Tagaro code into SVN?

[Parker Coates]

On Wed, Apr 13, 2011 at 11:55, Stefan Majewsky wrote:
>> On Wed, Apr 13, 2011 at 5:36 PM, Stefan Majewsky wrote:
>> my problem with libtagaro is that I want to use it in kdegames now,
>> and add more useful components it, but that's not possible because it
>> would then become a dependency, and very likely a hard one (unless
>> someone is willing to maintain the non-Tagaro codepaths).
>>
>> So, without further ado: Would anybody mind if I moved the Tagaro
>> source tree inside kdegames SVN, in a separate subdirectory? It will
>> explicitly be described as an experimental and private library, with
>> headers being installed only when the undocumented option
>> -DINSTALL_HIGHLY_UNSTABLE_TAGARO_INCLUDES is given to CMake.
>>
>> If nobody offends until the weekend, I'll do the commit. I will not
>> commit the whole history, as I see no added value in having it. Only
>> the then-current master branch from git.kde.org/libtagaro.

Why throw away the history? In my experience, when code spelunking
more information is almost always better than less. More than once
I've been stopped in my tracks when investigating the KPat's history
by a large "import a whole new version of KPat from elsewhere" commits
that happened over a decade ago.

>> I know that this proposed procedure bypasses kdereview effectively,
>> but big parts of Tagaro are already source-copied into kdegames
>> somewhere, like TagaroAudio in Granatier and parts of TagaroInterface
>> in Kolf. Also, KGameRenderer shares much with TagaroGraphics, so there
>> is not much new code in there. Besides, I will of course issue a
>> public review via kdereview when the library API is stabilized and
>> goes public.

If it means adding a new library for distributions to package, I think
it has to go through kdereview, even if it does so with a "this is not
a stable API" disclaimer. It's a relatively big change, so I think
third parties (packagers, build system folks, translators, etc.)
should have the opportunity to point out issues it may cause for them.

> What I forgot to mention: Tagaro will make QCA2 a hard dependency. As
> of now, OpenAL and libsndfile are also hard dependencies. All of these
> are already optional dependencies of the kdegames module, so if you
> keep an eye on CMake's feature log and install missing optionals, you
> are fine.

What exactly do you mean by "hard dependencies"? Hard dependencies of
the entire module? Or dependencies of libtagaro, which would then be a
dependency on the apps that use it, but the unaffected applications
would continue to be built if they were missing?

I'd like to say (as believe I have before) that I fully support you
Tagaro efforts. I'm just cautious. With our current limited manpower
situation, I'd hate to see a big change done only partially or
unsuccessfully without anyone around to clean up the resulting mess.
Maybe I'm just being paranoid, though. :)

Parker

Parker