KDE Games/Git Conversion Progress: Difference between revisions

From KDE Community Wiki
(→‎The Table: Those rules are there.)
No edit summary
Line 18: Line 18:
=== The Checks ===
=== 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.
; Main history : 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. [http://websvn.kde.org/trunk/KDE/kdegames/kshisen/?view=log Example]
; 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.
; 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. In very early revisions there can be a doc/ or html/ folder inside the game.
; Heads : 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. <syntaxhighlight lang="bash">git log --format='%h %p' --all | grep '^[0-9a-f]\+ *$'</syntaxhighlight> (if that shows more than one commit, something is wrong)
; 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.
; 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.
; Tags: All relevant release tags are present. If a game entered the kdegames module for the 4.3 release, it should have tags "v4.x.y" and newer.
; 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.)
; 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 "gitk --all" or "qgit --all" 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.)


== The Table ==
== The Table ==

Revision as of 19:24, 30 March 2012

This page is used to keep track of progress in KDEGames's conversion from SVN to Git.

How to Fill Out the Table

Rule Writers

The progress table uses a Mediawiki template with named parameters, to make it easier to edit than the raw table markup.

  • When you start writing rules for a particular game, add your initials in a rulesby= parameter, and set inprogress=1; for example rulesby=NA|inprogress=1. This will 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 and remove inprogress=1 from the table. The "Rules" column will automatically turn into a link pointing to the rules file.
  • Once you've generated a repository from the rules and verified its correctness, push it some place public, preferably a personal scratch repo. Add a scratch= param with the scratch repository path, and a scratchby= param with your initials; for example scratch=scratch/nalvarez/kdegames-foo.git|scratchby=NA.

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

Main history
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. Example
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. In very early revisions there can be a doc/ or html/ folder inside the game.
Heads
The repository has only one head. (git branch -r) Two heads mean a broken master branch.
git log --format='%h %p' --all | grep '^[0-9a-f]\+ *$'
(if that shows more than one commit, something is wrong)
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 "v4.x.y" and newer.
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 "gitk --all" or "qgit --all" 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.)

The Table

Rules Repo Completeness Docs Heads Stable branches Tags Branches
Bomber PC PC
Bovo PC PC
Granatier MK MK
Kajongg WR WR
Kapman PC PC MK MK MK MK MK MK
Katomic WR WR
KBlackBox WR WR
KBlocks PC PC
KBounce WR WR
KBreakout PC PC
KDiamond SM SM
KFourInLine FS
KGoldrunner FS FS [1]
Kigo PC PC
Killbots PC PC
Kiriki PC PC
KJumpingCube FS
Klickety NH% NH
KLines FS
KMahjongg WR WR
KMines PC%
KNavalBattle FS
KNetWalk PC PC
Kolf WR WR
Kollision PC PC
Konquest FS
KPatience NA
KReversi WR WR
KShisen FS
KSirk WR WR
KSnake WR WR
KSpaceDuel WR WR
KSquares PC PC
KSudoku PC PC WR WR WR WR WR:not OK in scratch, only when using latest svn2git WR
KTuberling NA
Kubrick PC PC
libkdegames SM%
libkmahjongg WR WR CK CK CK CK
Lieutenant Skat WR WR
Palapeli SM%

Contributor Initials

CK
Christian Krippendorf
FS
Frederik Schwarzer
MK
Mathias Kraus
NA
Nicolás Alvarez
NH
Ni Hui
PC
Parker Coates
SM
Stefan Majewsky
WR
Wolfgang Rohdewald