This section is addressed to the Django committers and to anyone interested in knowing how code gets committed into Django core.
Django has two types of committers:
These are people who are “domain experts.” They have direct check-in access to the subsystems that fall under their jurisdiction, and they’re given a formal vote in questions that involve their subsystems. This type of access is likely to be given to someone who contributes a large subframework to Django and wants to continue to maintain it.
Partial commit access is granted by the same process as full committers. However, the bar is set lower; proven expertise in the area in question is likely to be sufficient.
Decisions on new committers will follow the process explained in How we make decisions. To request commit access, please contact an existing committer privately. Public requests for commit access are potential flame-war starters, and will be ignored.
Please follow these guidelines when committing code to Django’s Subversion repository:
For any medium-to-big changes, where “medium-to-big” is according to your judgment, please bring things up on the django-developers mailing list before making the change.
If you bring something up on django-developers and nobody responds, please don’t take that to mean your idea is great and should be implemented immediately because nobody contested it. Django’s lead developers don’t have a lot of time to read mailing-list discussions immediately, so you may have to wait a couple of days before getting a response.
Write detailed commit messages in the past tense, not present tense.
For commits to a branch, prefix the commit message with the branch name. For example: “magic-removal: Added support for mind reading.”
Limit commits to the most granular change that makes sense. This means, use frequent small commits rather than infrequent large commits. For example, if implementing feature X requires a small change to library Y, first commit the change to library Y, then commit feature X in a separate commit. This goes a long way in helping all core Django developers follow your changes.
Separate bug fixes from feature changes.
Bug fixes need to be added to the current bugfix branch as well as the current trunk.
If your commit closes a ticket in the Django ticket tracker, begin your commit message with the text “Fixed #abc”, where “abc” is the number of the ticket your commit fixes. Example: “Fixed #123 – Added support for foo”. We’ve rigged Subversion and Trac so that any commit message in that format will automatically close the referenced ticket and post a comment to it with the full commit message.
If your commit closes a ticket and is in a branch, use the branch name first, then the “Fixed #abc.” For example: “magic-removal: Fixed #123 – Added whizbang feature.”
For the curious: we’re using a Trac post-commit hook for this.
If your commit references a ticket in the Django ticket tracker but does not close the ticket, include the phrase “Refs #abc”, where “abc” is the number of the ticket your commit references. We’ve rigged Subversion and Trac so that any commit message in that format will automatically post a comment to the appropriate ticket.
Write commit messages for backports using this pattern:
[<Django version>] Fixed <ticket> -- <description>
Backport of <revision> from <branch>.
For example:
[1.3.X] Fixed #17028 - Changed diveintopython.org -> diveintopython.net.
Backport of r17115 from trunk.
Nobody’s perfect; mistakes will be committed. When a mistaken commit is discovered, please follow these guidelines:
Jul 07, 2017