User:Majewsky/kdegames git proposal: Difference between revisions
| (One intermediate revision by the same user not shown) | |||
| Line 8: | Line 8: | ||
* Pro monolithic: lower entry barrier for developers from other modules | * Pro monolithic: lower entry barrier for developers from other modules | ||
== | == "Duolithic" proposal == | ||
I'm in favor of the monolithic approach, which suffers the main technical problem that a single kdegames repo with all history would be 500 MB, of which 108 MB are just the current checkout of trunk/KDE/kdegames. However, about 80 of 108 MB amount to themes, sounds and level data. | I'm in favor of the monolithic approach, which suffers the main technical problem that a single kdegames repo with all history would be 500 MB, of which 108 MB are just the current checkout of trunk/KDE/kdegames. However, about 80 of 108 MB amount to themes, sounds and level data. | ||
I therefore propose to form a new module kdegames-data which collects all such data files. Then only the code part (i.e. the kdegames module minus everything in kdegames-data) moves to a single Git repository. To benefit from the size reduction, we restart the repository without history and create a separate kdegames-history repository which also contains the data files, as it was until the creation of the kdegames-data repo. kdegames-data stays in SVN until a viable solution has been found for handling big masses of binary data files in Git. | I therefore propose to form a new module kdegames-data which collects all such data files. Then only the code part (i.e. the kdegames module minus everything in kdegames-data) moves to a single Git repository. To benefit from the size reduction, we restart the repository without history and create a separate kdegames-history repository which also contains the data files, as it was until the creation of the kdegames-data repo. | ||
kdegames-data stays in SVN until a viable solution has been found for handling big masses of binary data files in Git. The kdegames-data module is declared to have a build-time dependency on kdegames. | |||
== Projected outcome == | == Projected outcome == | ||
| Line 28: | Line 30: | ||
# use the existing monolithic rules to create the kdegames-history repo | # use the existing monolithic rules to create the kdegames-history repo | ||
# create the kdegames repo from a plain checkout of trunk/KDE/kdegames | # create the kdegames repo from a plain checkout of trunk/KDE/kdegames | ||
== FAQ == | |||
Some additional explanations which did not fit in the thought flow above: | |||
; Why does kdegames-data depend on kdegames in the proposal? | |||
: This will allow to use executables from kdegames in the kdegames-data build process. For example, Palapeli would directly benefit from being able to use libpala-puzzlebuilder to build the standard puzzles. | |||
; Why the requirement to make apps work without the data files from kdegames-data? | |||
: This is to ensure that developers are not dependent on artists when they change the format of data files e.g. by adding new visual elements to themes. | |||
Latest revision as of 22:28, 2 March 2011
General considerations of repository layout
- Pro split: checkout for single applications possible and smaller
- Pro split: apps can be moved in and out without problems
- Pro monolithic: reflects better general structure of development community (few maintainers for many apps)
- Pro monolithic: additions to libkdegames et.al. can be propagated to the apps without problems
- Pro monolithic: lower entry barrier for developers from other modules
"Duolithic" proposal
I'm in favor of the monolithic approach, which suffers the main technical problem that a single kdegames repo with all history would be 500 MB, of which 108 MB are just the current checkout of trunk/KDE/kdegames. However, about 80 of 108 MB amount to themes, sounds and level data.
I therefore propose to form a new module kdegames-data which collects all such data files. Then only the code part (i.e. the kdegames module minus everything in kdegames-data) moves to a single Git repository. To benefit from the size reduction, we restart the repository without history and create a separate kdegames-history repository which also contains the data files, as it was until the creation of the kdegames-data repo.
kdegames-data stays in SVN until a viable solution has been found for handling big masses of binary data files in Git. The kdegames-data module is declared to have a build-time dependency on kdegames.
Projected outcome
We have a size-optimized Git repository that contains only code (plus, possibly, a bare minimum of data which is required so that apps don't crash because of missing data).
Whoever wants to compile, test or work on kdegames will just need two repos. Developers working on the apps will usually not need to update the kdegames-data repo unless the format of data changes (e.g. when new elements are added to themes), and designers will usually not need to update the kdegames repo with the same exception.
Packagers will probably want to build separate data packages for all games from that point because the CMakeLists of kdegames and kdegames-data are separate. The packages generated from kdegames will have hard dependencies on the packages generated from kdegames-data, so that end users installing the app get the data automatically.
Proposed action plan
- split kdegames-data from kdegames in SVN
- modify applications such that they work without the data (work as in: not crash) or include some dummy data files which are used only as an absolute fallback
- use the existing monolithic rules to create the kdegames-history repo
- create the kdegames repo from a plain checkout of trunk/KDE/kdegames
FAQ
Some additional explanations which did not fit in the thought flow above:
- Why does kdegames-data depend on kdegames in the proposal?
- This will allow to use executables from kdegames in the kdegames-data build process. For example, Palapeli would directly benefit from being able to use libpala-puzzlebuilder to build the standard puzzles.
- Why the requirement to make apps work without the data files from kdegames-data?
- This is to ensure that developers are not dependent on artists when they change the format of data files e.g. by adding new visual elements to themes.