Commit rules

== 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-3.22/*
* client/include/*
* common/*
* common/aicore/*
* common/networking/*
* common/scriptcore/*
* data/hexemplio/*
* data/civ2civ3/*
* data/default/*
* data/misc/*
* data/nation/*
* server/*
* server/generator/*
* server/savegame/*
* 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 Github 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 Github access for at least a month. Commit message should remain meaningful, and patches with extensive comment changes should still be submitted to the tracker.
* Exception: Some maintenance commits are pushed without prior patch in the a tracker. These are mostly related to release process, and other milestone updates.
Remember to list the bug tracker number in the commit to allow easy cross-referencing from the commit history into the discussion about a particular issue, and vice versa. Use a form like "See osdn #12345" or "See hrm #123456".
=== 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 Accepted (Resolved in hrm). 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 Accepted 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.
* In some cases (see below) Vulnerability fixes
=== Vulnerability fixes ===
If the vulnerability is not widely known, the fix should be handled in secrecy between Maintainers, and in cooperation with other projects, e.g., in case it affects downstreams. In most cases 36h/24h review time applies to any such fix shared between Maintainers.
If the vulnerability is already widely known, fix can be handled like any other patch in the ticket tracker. Depending on seriousness of the situation it can be consider a critical bug fix that one may push immediately.
=== 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, 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.
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 Git source tree, make sure that the file properties are in order:
* Text files should be committed with Linux style LF line endings (\n), not Windows style CR+LF - you can use the Linux tool 'flip' to make sure it is correct: flip -ubv filename.c
* Files that need to be executable, such as shell scripts, should have their executable bit set in the filesystem.
==See also==
*Marko's Testing tips
Category:Coding
Category:Source code repository