Commit Policy

Qt Commit Policy

These are the general rules for creating and pushing commits to any shared Qt repositories. As usual at Qt, none of these rules is set in stone, but you will be subject of public reprimand if you violate them without good reason.

1. If you add new functions/classes:
   ## Ensure everything is documented properly.
   ## Follow the API Design Principles. Discuss and verify the names of functions/classes with other Qt developers (conduct API reviews).
   # All code should follow the Coding Conventions.
   # For GUI code, follow the "style guide":http://techbase.kde.org/Projects/Usability/HIG , the Qt Creator translation hints and avoid "internationalization mistakes":http://techbase.kde.org/Development/Tutorials/Localization/i18n_Mistakes.
   # Ensure your change compiles and works on all platforms. The CI system will not allow your change to go in if it does not compile.
   # Verify that there are no regressions in the unit tests (see Public Autotest Infrastructure for more info).
   # Write new unit tests for the bugs you fixed or functionality you added.
   # Make your new/changed code follow the coding style.
   # Produce commits which facilitate reviews and contribute to a useful history which can be read, searched, annotated and cherry-picked. In particular:
   ## Make atomic commits. That means that each commit should contain exactly one self-contained change - do not mix unrelated changes, and do not create inconsistent states. Never "hide" unrelated fixes in bigger commits. Make coding style fixes only in exactly the lines which contain the functional changes, and comment fixes only when they relate to the change - the rest is for a separate commit.
   ## Write descriptive commit messages. Make them self-contained, so people do not have to research the historical context to make sense of them. Conversely, do not put unnecessary trivia into them. Tell why you changed something unless it is completely self-evident; this is particularly important for reverts. Use the "Qt commit template":http://qt.gitorious.org/qt/qt5/blobs/dev/.commit-template. Follow the summary + description message style and use footers to reference JIRA issues, reviewers, etc. and consider the "generic Git commit message guidelines":http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html.
   ## Commit often. Use <code&gt;git gui&lt;/code&gt; and <code&gt;git rebase -i&lt;/code&gt; extensively to get your unpublished history into shape. Note that pushing to your private clone does not count as publishing and is a perfectly valid way to solicit an early review or to make a backup of a work in progress. Further reading: "Understanding the Git Workflow&quot;:http://sandofsky.com/blog/git-workflow.html
   ## Avoid unnecessary merges. Use <code&gt;git pull —rebase&lt;/code&gt; unless you have an unpushed "proper&quot; merge. Our Gerrit permits only trusted Merge Masters to push merge commits.
   # Do not commit anything you do not understand. "Somehow it suddenly works&quot; is not acceptable. Reverting when a proper fix would be possible is admitting defeat. ;)
   # Review your changes before you push to Gerrit. <code&gt;git log [—stat] [—summary] [-p] {u}..</code&gt; and <code&gt;gitk&lt;/code&gt; are your friends.
# Make sure you submit against the lowest applicable branch from which a release is still planned. Cherry-picks ("backports&quot;) are frowned upon, while forward-merging to more recent branches happens "automatically&quot; on a regular basis. Exception: As Qt 4 and Qt 5 live in separate repositories, changes must be applied to Qt 5 first (successfully merged; passed integration) and then be cherry-picked to Qt 4.
# Peer review is strongly encouraged. Do not approve your own changes. Discuss objections.
#* If there is no candidate for a review yet, introduce somebody to the code.
#* Maintainer privilege: A maintainer may approve his own change to the code he maintains if
#' at least one review (+1) from somebody else is present, and
#' nobody else who could approve (+2) the change can be produced within reasonable time
# Do not ignore/fight the Early Warning System. Justify each override.
# And most importantly: use your brain.

Change Log

If the change is significant and affects many users, compatibility, or is a noteworthy feature, you must add a ChangeLog tag. Conversely, do not ChangeLog entries that are not relevant to users.
* A [ChangeLog] entry can be multiple lines long and ends with an empty newline.
* Try to integrate the changelog entry into the surrounding commit message to avoid redundancy.
* If the Git repository contains multiple modules, use the module name to indicate the area of the change e.g. [QtCore].
* Optionally specify a class or subtopic [QtNetwork][QSslSocket]
* Other common tags are:
' [General]
' [Important Behavior Changes]
' [Platform Specific Changes]
' [Windows]
' [OS X]
' [Linux/XCB]
* In summary the entry should look like this:
<code&gt;
[ChangeLog][module][class/topic] description of the really important
change that was just made (on several lines).
</code&gt;
' The description should use either simple past ("Fixed …") or be explicit about refering to the current state ("… does now …").
' Make sure the entry is reasonably self-contained. If you fail to formulate a meaningful description, it's probably not useful information to start with.

Additional notes

• When you commit translations, use "make commit-ts&quot; instead of "git commit&quot; to keep the line number information out of the committed files.
• When you need configure.exe recompiled, let the designated "compile master&quot; (currenly Oswald.Buddenhagen at digia.com, ossi|tt on IRC) do that for you in a separate commit. We try to batch recompiles and always do them in the same build configuration to keep the git repository bloat down.