KDE Games/Git Conversion Progress: Difference between revisions

Revision as of 01:07, 10 March 2012

How to Fill Out the Table

Rule Writers

When you start writing rules for a particular game, add your initials to the "Rules" column followed by a '%' to indicate that the rules are in progress so that efforts aren't duplicated.
Once you've written the rules and feel they're complete, push them to the kdegames directory of the kde-ruleset repository. Make your initials in the "Rules" column a link pointing to the rules file and remove the '%'.
Once you've generated a repository from the rules and verified its correctness, push it some place public, preferably a personal scratch repo. Add your initials in the "Repo" column as a link pointing to the repository webpage.

Repository Checkers

It is assumed that the rule writer has already verified the correctness of the repository, so don't bother adding yourself to the table.
Checkout the repository, poke around a bit and then perform each of the following checks, adding your initials in each column. Ideally, more than one person should check each repo, in which case, separate each set of initials with a comma.

The Checks

Completeness: The complete history is present. The first commit should be the initial import into KDE's CVS or SVN. All transitions from playground, kdereview, extragear, KDE3, etc. should be present.
Docs: The user documentation is in a subdirectory named "doc". The history of the doc folder should match that of the "kdegames/doc/<game>" folder.
Metadata: Commit messages contain the original SVN path and revision numbers. (--add-metadata was used during conversion.)
Heads: The repository has only one head. (git branch -r) Two heads mean a broken master branch.
Stable branches: All relevant stable branches are present. If a game entered the kdegames module for the 4.3 release, it should have a stable branch "KDE/4.x" for each x >= 3 and none for x < 3.
Tags: All relevant release tags are present. If a game entered the kdegames module for the 4.3 release, it should have tags "KDE/4.x.y" for each x >= 3 and none for x < 3.
Branch names: All stable branches are of the format "KDE/X.Y" and all release tags are of the format "vX.Y.Z".
Branches: If the game has a non-linear history (i.e. work branches were created and later merged back in to trunk) that should be recreated in the Git history. This is by far the most difficult check. Use git gui to visualise branches and merges, but you have to know what you're looking for. Fortunately, this isn't required for games that have a simple playground -> kdereview -> kdegames history. To determine where an application has been throughout its history, enter its name into this page, which will return all known SVN change paths containing the name. (Pay no attention to the l10n and www stuff.)

Contributor Initials

MK: Mathias Kraus
NA: Nicolás Alvarez
PC: Parker Coates
WR: Wolfgang Rohdewald
FS: Frederik Schwarzer

The Table

	Rules	Repo	Completeness	Docs	Metadata	Heads	Stable branches	Tags	Branch names	Branches
Bomber	PC	PC
Bovo	PC	PC
Granatier	MK	MK
Kajongg	WR	WR
Kapman	PC	PC	MK	MK	MK	MK	MK	MK	MK	MK
Katomic
KBlackBox
KBlocks	PC	PC
KBounce
KBreakout	PC	PC
KDiamond
KFourInLine
KGoldrunner
Kigo	PC	PC
Killbots	PC	PC
Kiriki	PC%	PC
KJumpingCube
Klickety
KLines
KMahjongg	WR%
KMines
KNavalBattle
KNetWalk	PC%
Kolf
Kollision	PC	PC
Konquest
KPatience	NA%
KReversi
KShisen	FS%
KSirk
KSnakeDuel
KSpaceDuel
KSquares	PC	PC
KSudoku	PC	PC
KTuberling	NA%
Kubrick	PC	PC
libkdegames
libkmahjongg	WR	WR
Lieutenant Skat
Palapeli

@@ Line 14: / Line 14: @@
 === The Checks ===
-; Check1 : The complete history is present. The first commit should be the initial import into KDE's CVS or SVN. All transitions from playground, kdereview, extragear, KDE3, etc. should be present.
+; Completeness : The complete history is present. The first commit should be the initial import into KDE's CVS or SVN. All transitions from playground, kdereview, extragear, KDE3, etc. should be present.
-; Check2 : The user documentation is in a subdirectory named "doc". The history of the doc folder should match that of the "kdegames/doc/<game>" folder.
+; Docs : The user documentation is in a subdirectory named "doc". The history of the doc folder should match that of the "kdegames/doc/<game>" folder.
-; Check3 : Commit messages contain the original SVN path and revision numbers. (--add-metadata was used during conversion.)
+; Metadata : Commit messages contain the original SVN path and revision numbers. (--add-metadata was used during conversion.)
-; Check4 : The repository has only one head. (git branch -r) Two heads mean a broken master branch.
+; Heads : The repository has only one head. (git branch -r) Two heads mean a broken master branch.
-; Check5 : All relevant stable branches are present. If a game entered the kdegames module for the 4.3 release, it should have a stable branch "KDE/4.x" for each x >= 3 and none for x < 3.
+; Stable branches : All relevant stable branches are present. If a game entered the kdegames module for the 4.3 release, it should have a stable branch "KDE/4.x" for each x >= 3 and none for x < 3.
-; Check6 : All relevant release tags are present. If a game entered the kdegames module for the 4.3 release, it should have tags "KDE/4.x.y" for each x >= 3 and none for x < 3.
+; Tags: All relevant release tags are present. If a game entered the kdegames module for the 4.3 release, it should have tags "KDE/4.x.y" for each x >= 3 and none for x < 3.
-; Check7 : All stable branches are of the format "KDE/X.Y" and all release tags are of the format "vX.Y.Z".
+; Branch names : All stable branches are of the format "KDE/X.Y" and all release tags are of the format "vX.Y.Z".
-; Check8 : If the game has a non-linear history (i.e. work branches were created and later merged back in to trunk) that should be recreated in the Git history. This is by far the most difficult check. Use git gui to visualise branches and merges, but you have to know what you're looking for. Fortunately, this isn't required for games that have a simple playground -> kdereview -> kdegames history. To determine where an application has been throughout its history, enter its name into [http://stuff.povaddict.com.ar/kde-svn-search.php this page], which will return all known SVN change paths containing the name. (Pay no attention to the l10n and www stuff.)
+; Branches : If the game has a non-linear history (i.e. work branches were created and later merged back in to trunk) that should be recreated in the Git history. This is by far the most difficult check. Use git gui to visualise branches and merges, but you have to know what you're looking for. Fortunately, this isn't required for games that have a simple playground -> kdereview -> kdegames history. To determine where an application has been throughout its history, enter its name into [http://stuff.povaddict.com.ar/kde-svn-search.php this page], which will return all known SVN change paths containing the name. (Pay no attention to the l10n and www stuff.)
 == Contributor Initials ==
@@ Line 35: / Line 36: @@
 {| style="background-color:#EEEEEE"
 |-
-! !! Rules !! Repo !! Check1 !! Check2 !! Check3 !! Check4 !! Check5 !! Check6 !! Check7 !! Check8
+! !! Rules !! Repo !! Completeness !! Docs !! Metadata !! Heads !! Stable branches !! Tags !! Branch names !! Branches
 |-
 ! Bomber