Qt Contribution Guidelines

Qt Contribution Guidelines

We have a community around the development of the Qt libraries, Qt related tools and add-ons. These guidelines will introduce you to the tools and mechanics as well as to the philosophies behind the development of Qt. You will learn how to set up your development environment for working on the library itself and how to submit code/documentation for inclusion.

Prerequisites

First you have to get the Qt source code and set up your local working environment to build Qt. See Get The Source for instructions.

Style, Conventions and Principles

For development of the Qt framework we follow the framework's Coding Style and we stick to our established Coding Conventions. The "KDE Library Code Policy":http://techbase.kde.org/Policies/Library_Code_Policy is based on Qt's, so much is shared with Qt's. You can find more information there that isn't in Qt pages.

Qt Creator uses its own "Qt Creator Specific Coding Style & Conventions":http://doc.qt.digia.com/qtcreator-extending/coding-style.html. It is similar to the Qt framework's coding style and conventions, but there are some differences and additions.

In addition, conventions for writing good user interface messages texts that play well with Qt Linguist can be found under UI Text Conventions.

Our API Design Principles aim for perfection.

Note that Qt is an open source library, and must therfore be compilable in its completeness using freely available tools and libraries. This means that you should not contribute code that uses any kind of private APIs.

Please follow the Commit Policy.

Verify that your commits have correct author information, including your name and email address as it is registered in gitorious.org.

Localization to Other Languages

The process of contributing translations is described in Qt Localization.

Making Changes to Qt

The Git Introduction page describes a basic workflow of using Git to create changes, while the Gerrit Tutorial in detail describes how our version of Gerrit works for the Qt Project.

Make sure it compiles with Qt In Namespace.

Submitting your changes for inclusion into Qt

There are some steps you need to follow only once:

1. "Create an account":http://bugreports.qt.io on the Qt Project bug tracker (Jira). This will be the same login information you will use in the "Gerrit code review system":http://codereview.qt.io. Even though the account credentials are shared, you still need to complete the account details on the "Gerrit code review system":http://codereview.qt.io. See the next step.
2. Login on and set up "your Gerrit account":http://codereview.qt.io/#settings,contact by adding your full name, email address, and public SSH key.
3. Review and agree to the Qt Project's contribution agreement in Gerrit. You only need to do this once, unless the license changes. If your company has a corporate contribution agreement, ask the owner of the according Gerrit user group to add your account to this group.
4. Clone Qt from the read-only mirror.
   • Qt 4: Add a git remote called "gerrit" in your cloned repository, which points to the Qt 4 project on codereview.qt.io.
   • Qt 5: When you run the init-repository script, provide your Gerrit username to the —codereview-user option.

Then there are steps you need to follow for each patch you contribute:

1. Push you changes to remote "gerrit" to the branch refs/for/master, if master is the branch you are targeting.
2. The Early Warning System (EWS) will quickly kick in and check your patch. Please act upon the reports and push updates to the patch.
3. Add relevant reviewers to your change(s). If you don't do this, your change may go unnoticed. To find possible reviewers, you can:
   • examine the Git history with 'git log' and/or 'git blame',
   • see the Maintainer chart,
   • ask on IRC, or
   • ask on relevant mailing lists like development@qt-project.org or qt-creator@qt-project.org etc.
4. Wait for reviews, and actively partake in the review of your change(s).
   • If your contribution is deemed to not align with the project's vision or goals, you should abandon the change at this point.
   • If your contribution is deemed unready, you need to fix it up according to the reviews.
5. Submit your patch. If your contribution satisfies the technical requirements, then you or the Approver are able to submit the patch into the staging branch, or directly into the target branch, if there's no CI system on that particular branch and/or repository.
   • To determine if the branch is covered by the CI system, you may check "the CI logs":http://testresults.qt.io/ci/ ; if the project/branch can be found at this link, it is covered by CI.
   • If the continuous integration (CI) system rejects your patch, you need to fix the issues so it passes the project's build and autotest systems.
6. When CI is successful, your changes are automatically included and added to the official Qt repository.

Developer's Lounge

If you have any questions about the development of Qt, feel free to join the #qt-labs IRC channel on irc.freenode.net and the "Qt development mailing list":http://lists.qt.io/mailman/listinfo/development Qt Creator development, join #qt-creator on irc.freenode.net and the "Qt Creator mailing list":http://lists.qt.io/mailman/listinfo/qt-creator.