KDE Games/IRC Meetings/Git Conversion 1: Difference between revisions
Appearance
Page layout. |
→Topics: Fix wiki link. |
||
(7 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
== Date/Time == | == Date/Time == | ||
Friday 30th March 2011 | |||
== Topics == | == Topics == | ||
Line 9: | Line 6: | ||
: What is the latest date we want to switch at in the 4.9 roadmap? | : What is the latest date we want to switch at in the 4.9 roadmap? | ||
: Maybe make a little roadmap for the migration? | : Maybe make a little roadmap for the migration? | ||
: http://techbase.kde.org/Schedules/KDE4/4.9_Release_Schedule | |||
* we want to have everything in place before | |||
** May 10: the dependency freeze (changing the buildsystem changes dependencies) | |||
** May 17: the beta 1 tag (when packagers start to pick up our code) | |||
* so '''May 10''' is the deadline | |||
; Actual conversion | ; Actual conversion | ||
Line 14: | Line 18: | ||
: - On what machine? | : - On what machine? | ||
: - All in one go or every game on its own? | : - All in one go or every game on its own? | ||
* rules are tested on ssh://dewey.kde.org | |||
; Finalise check descriptions | ; Finalise check descriptions | ||
: This should be done to make | : This should be done to make it possible to check finished repos and be sure we get all the issues checked. If the rules are modified, all previous check-marks should be reset. | ||
: [[KDE Games/Git Conversion Progress]] | |||
* there are basic scripts for "test-driven rule writing" in a branch of kde-ruleset.git, but PovAddict is dropping work on them out of pragmatism because we'd never get done otherwise | |||
* check list at [[KDE Games/Git Conversion Progress]] has been updated and former "done" marks have been reset | |||
; Existing rules files | ; Existing rules files | ||
: Short and rough review to get some questions off the table and to get all rules somewhat unified throughout KDEGames. | : Short and rough review to get some questions off the table and to get all rules somewhat unified throughout KDEGames. Peer review anyone? | ||
: http://quickgit.kde.org/?p=kde-ruleset.git | |||
; Existing conversion/postprocessing scripts | ; Existing conversion/postprocessing scripts | ||
: Short and rough review of the existing to point out possible flaws or inconsistencies in the way they work. Maybe find a unified structure for all | : Short and rough review of the existing scripts to point out possible flaws or inconsistencies in the way they work. Maybe find a unified script structure for all games. | ||
; CMake preparation | ; CMake preparation | ||
: All games should be able to be compiled on their own before the conversion | : All games should be able to be compiled on their own AND as a module. CMake changes before or after the conversion? How to do that? | ||
* There is a guide at http://old.nabble.com/KDE-Multimedia-SVN-to-GIT-:-Migrate-your-own-module-Cookbook-td33520409.html | |||
* I suggest doing it before the conversion, otherwise the buildsystem will be broken between conversion and CMake-fixing. -- PovAddict (+1 - majewsky) (Its what I did for kdemm --tdfischer) | |||
* CMake files for libkdegames need love: | |||
** move from FindLibKdeGames.cmake to CMake EXPORTs | |||
*** documentation on how to write one: http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file | |||
** detect library version (esp. relevant for extragear and playground, where old and new APIs need to be targeted) | |||
*** workaround (from schuay): http://pastie.org/private/q3mkiwj04onlsg2naiiaq | |||
* All subdirs must be able to build standalone (as an option!) and detect the new libkdegames API version. | |||
* The superbuild maintainer needs to know library dependencies per app. | |||
** Most apps need just libkdegames and basic kdelibs stuff. | |||
** Then there's Phonon (which should be ported to KgSound BTW), OpenGL (Kubrick, KSudoku) and QCA (KSirk). |
Latest revision as of 20:16, 27 April 2012
Date/Time
Friday 30th March 2011
Topics
- Deadline
- What is the latest date we want to switch at in the 4.9 roadmap?
- Maybe make a little roadmap for the migration?
- http://techbase.kde.org/Schedules/KDE4/4.9_Release_Schedule
- we want to have everything in place before
- May 10: the dependency freeze (changing the buildsystem changes dependencies)
- May 17: the beta 1 tag (when packagers start to pick up our code)
- so May 10 is the deadline
- Actual conversion
- - Who will do it?
- - On what machine?
- - All in one go or every game on its own?
- rules are tested on ssh://dewey.kde.org
- Finalise check descriptions
- This should be done to make it possible to check finished repos and be sure we get all the issues checked. If the rules are modified, all previous check-marks should be reset.
- KDE Games/Git Conversion Progress
- there are basic scripts for "test-driven rule writing" in a branch of kde-ruleset.git, but PovAddict is dropping work on them out of pragmatism because we'd never get done otherwise
- check list at KDE Games/Git Conversion Progress has been updated and former "done" marks have been reset
- Existing rules files
- Short and rough review to get some questions off the table and to get all rules somewhat unified throughout KDEGames. Peer review anyone?
- http://quickgit.kde.org/?p=kde-ruleset.git
- Existing conversion/postprocessing scripts
- Short and rough review of the existing scripts to point out possible flaws or inconsistencies in the way they work. Maybe find a unified script structure for all games.
- CMake preparation
- All games should be able to be compiled on their own AND as a module. CMake changes before or after the conversion? How to do that?
- There is a guide at http://old.nabble.com/KDE-Multimedia-SVN-to-GIT-:-Migrate-your-own-module-Cookbook-td33520409.html
- I suggest doing it before the conversion, otherwise the buildsystem will be broken between conversion and CMake-fixing. -- PovAddict (+1 - majewsky) (Its what I did for kdemm --tdfischer)
- CMake files for libkdegames need love:
- move from FindLibKdeGames.cmake to CMake EXPORTs
- documentation on how to write one: http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file
- detect library version (esp. relevant for extragear and playground, where old and new APIs need to be targeted)
- workaround (from schuay): http://pastie.org/private/q3mkiwj04onlsg2naiiaq
- move from FindLibKdeGames.cmake to CMake EXPORTs
- All subdirs must be able to build standalone (as an option!) and detect the new libkdegames API version.
- The superbuild maintainer needs to know library dependencies per app.
- Most apps need just libkdegames and basic kdelibs stuff.
- Then there's Phonon (which should be ported to KgSound BTW), OpenGL (Kubrick, KSudoku) and QCA (KSirk).