Contributing your first patch to the Qt Project
summary
Covers the exact workflow to get a patch accepted: clone with git, pick the correct branch (Dev vs stable 5.x), write mandatory unit tests, follow existing style and commit-message rules (one-line ≤76 chars plus a why/body), push to Gerrit via refs/for and request reviewers, and click merge to staging after approvals. CI runs full tests (~3 hours per run), flaky concurrent failures require manual re-triggering. Notes on emulated GUI tests versus manual verification, developer-build flags, and SSH key setup are included.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 4:40Downloading the source code
- 7:23Activity in each branch
- 10:02Source code
- 13:20Unit tests
- 16:15Change log
- 18:51Submission
- 20:20git push
- 21:11git submission
- 22:17presentation
- 28:02conclusion
related talks
26mGit and Gerrit essentials for Qt based work
58mHow To Get Your Patch Accepted
37mGetting Your Patches in Mainline Linux: What Not To Do (& a Few Things You Could Try
45mFrom an Idea to a Patch in the Linux Mainline
49mMaking your patch more committable
44mContributing to Qt: From Zero to Hero
53mUpstreaming 201
01h 05mDrupal Contributions - A Pragmatic Approach to the Issue Queue