[Kde-games-devel] Module layout proposal: Split kdegames-data from kdegames

[Parker Coates]

On Fri, Oct 14, 2011 at 14:29, Stefan Majewsky wrote:
> ==== DETAILED PROPOSAL ====
>
> kdegames is among the few modules that have not yet switched to Git.
> The main concern is that the kdegames source tree contains tons [1] of
> binary data files, which Git is known not to handle well. All
> discussions about moving to Git (on scm-interest and games-devel) have
> just let to bikeshedding about how to handle the binary files with
> git. I propose to postpone this specific problem and move on with the
> Git transition *now*, especially since the solution I want to propose
> has added benefit.

Before going any further, I just want to confirm that this particular
proposal is stand-alone and independent of the
per-application-vs-monolithic-repository debate. That seems to be the
case, but I want to make sure I'm not missing anything. This
data-files-with-git issue is a particularly unpleasant one that'll
need to be solved either way.

> I propose to split a new module kdegames-data from kdegames, meaning that:
>
> 1. kdegames-data should be built and installed before kdegames.
> 2. Any kdegames application will refuse to start when the
> corresponding data files have not been installed.

Is there any reason we can't do all this with a kdegames/data
directory instead of a new top level module? Such a directory could
easily be left behind in the git migration, but in the meantime
kdegames/CMakeLists.txt could be modified to build the data directory
first and the current process of building KDEGames would be pretty
much unchanged. The existing per-application build flags could also be
used as is.

Of course there could reasons for preferring a top level module that
I'm just not seeing.

> Number 2 is a protective measure because, currently, about all games
> won't run correctly or look utterly broken without proper indication
> of the problem.

This seems like a reasonable thing to do regardless of the module
structure or version control system.

> If this proposal is implemented, the kdegames module, that is: the
> source code, can move to Git without worrying about the data files.
> These can move at any later point in time, when a wise solution has
> been worked out by our Git specialists. I'll repeat to get this clear:
> I'm not proposing to let the data stay in SVN forever. What I want is
> to disentangle the fates of the source code and the data files, for
> the benefit of both.
>
> The added benefit of this solution is that distributions will be
> encouraged to package data files separately. Because this data (and
> esp. its format) changes very seldomly only, developers will not need
> to checkout this giant mass of data from our SCM servers, but can
> instead use the packages provided by their distribution. The same
> holds true for drive-by contributors: They only have to clone a tiny
> repo containing the source code of the game which they want to hack
> on, without fetching megabytes of data files which they already had
> installed.

Personally I don't feel these advantages are significant enough to
justify doubling the number of packages shipped. Ideally, I would hope
that distributions will be able to work some magic to merge the
application and the data files back together again, to create a single
package per game as they do now. Of course I have no idea if this is
actually doable.

> 1. Create the new module in SVN, move data files from the current
> kdegames module. The toplevel directory is still divided by
> applications, of course.

Also, will the move preserve history for the data files? While history
is obviously less essential for data files than it is for source code,
it'd still be nice to have, especially to guide one to where the data
used to live.

> As has been said before, if there are no objections, I would like to
> implement this proposal starting from the end of next week (Sat,
> October 22), to make sure that the required changes get into 4.8.

No objections from me. Honestly, I don't like this solution; it seems
complicated and awkward. I had really been hoping that a better
solution would be brought forward, but one hasn't, so I see no reason
to delay any further.

Parker