Changes: Commit rules

Revision as of 11:43, 24 May 2015

Concept

The basic concept is that default modules of the tree are sensitive and optional modules are not. If a default module gets disturbed you will stall the work of the other developers. If an optional module gets disturbed the issues will have limited impact and the other developers may continue their work unimpaired.

Default modules

The files in these directories are critical for the game to function:

ai/*

client/*
client/gui-gtk-2.0/*
client/include/*

common/*
common/aicore/*

data/amplio/*
data/default/*
data/misc/*
data/nation/*

server/*
server/generator/*
server/scripting/*

The procedure for commits to these modules is as follows:

Patches must be posted to the bug tracker before commit in almost all cases. Critical bug fix patches may be committed immediately after post by anyone who has had SVN access for at least a month. Everyone else follows the rules for Normal patches.

Exception: minor improvements to comments may be committed without posting to the bug tracker first, by anyone who has had SVN access for at least a month. Commit message should remain meaningful, and patches with extensive comment changes should still be submitted to the tracker.

Remember to list the bug tracker number in the commit to allow easy cross-referencing from the SVN history into the discussion about a particular issue, and vice versa. Use a form like "See gna bug #12345" or "See gna patch #1234"; this allows the bug tracker to create links from tickets to commits.

Normal patches

When you start working on a ticket, ensure that it's assigned to yourself and set the status to In Progress to avoid duplication of effort. (Corollary: don't take others' In Progress tickets without asking.)

When a patch is ready, it must be posted to the bug tracker and the ticket status set to Ready For Test. Allow an adequate period of time in this state for comments (minimum 36 hours).

If there are comments, the patch should be modified accordingly and reposted by one of the interested parties. After reposting, the ticket status should once again be set to Ready For Test and time allowed for re-review (minimum 24 hours). Iterate.

If there are no more issues, the patch may be committed and the ticket closed.

Critical bug fix patches

A critical bug fix patch removes the causes of one or more of these effects:

Compilation failure.
Program startup failure.
Program lockup/infinite loop.
Premature program termination (e.g. core dump).
Data corruption.

Stable and Unstable periods

Normal development proceeds at a testing level of stability. But from time to time a higher or lower stability level is desired.

The stable branches of SVN, and the development branch immediately before branching, are considered stable. Extra care needs to be taken not to break the building or execution of the tree with these tags.
Sometimes when a large series of patches depend on each other, or when development is proceeding at a more rapid pace, patches may be integrated immediately to allow continued development. This should happen only with the consensus of other maintainers.
Extra care should be taken when modifying translatable strings during periods of high stability to allow translators to work effectively to complete their translations. In addition, any changes must be communicated to the freeciv-i18n mailing list. Leading up to a release, there is an additional period of strict string freeze - typically two weeks - where no string changes may be committed whatsoever.

Maintained optional modules

These modules are optional and have specific maintainers. These maintainers are responsible for the contents of these modules. If it gets broken it is their responsibility to fix it.

Client modules:

client/gui-ftwl/*
client/gui-gtk-2.0/* (also included in the Default modules)
client/gui-sdl/*
client/gui-win32/*
client/gui-xaw/*

Translation modules:

doc/{de, fr, it, ja, nl, sv}/*
po/*.po

The procedure for commits of patches to these modules is as follows:

Module maintainers

Module maintainers may commit patches immediately. It is considered polite to post the patches to the bug tracker before committing.

Everyone else

Follow the rules used for Default modules. It is considered polite to ask the module maintainer for comment before committing.

Non-Maintained optional modules

Follow the rules used for Default modules.

Committing new files

Before committing a new file to the subversion source tree, make sure that the svn properties are in order:

EOL style should be native (on a Linux system) - svn propset svn:eol-style native filename.c

In order for the above to work, line endings should be Linux style LF (\n) and not f.e. Windows style CR+LF (\r\n) - you can use the Linux tool 'flip' to make sure it is correct: flip -ubv filename.c

Appropriate executable property - set for f.e. shell scripts; unset for every other file.

svn propset svn:executable yes filename.sh
svn propdel svn:executable filename.svg

@@ Line 33: / Line 33: @@
 The procedure for commits to these modules is as follows:
-Patches must be posted to the bug tracker before commit in all cases.
+Patches must be posted to the bug tracker before commit in almost all cases.
 [[#Critical bug fix patches|Critical bug fix patches]] may be committed immediately after post by anyone
 who has had SVN access for at least a month. Everyone else follows the rules
 for [[#Normal patches|Normal patches]].
+* Exception: minor improvements to comments may be committed without posting to the bug tracker first, by anyone who has had SVN access for at least a month. Commit message should remain meaningful, and patches with extensive comment changes should still be submitted to the tracker.
 Remember to list the bug tracker number in the commit to allow easy cross-referencing from the [[Svn|SVN]] history into the discussion about a particular issue, and vice versa. Use a form like "See gna bug #12345" or "See gna patch #1234"; this allows the bug tracker to create links from tickets to commits.