This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 39 Next »

This document is intended to capture some of the policies we would like all committers to follow when it comes to checking in changes into our GIT repository.

Commit Log Format

Each commit to the repository must have a non-empty log message. The message format should start with a one-line short summary prefixed with the Jira issue number. If you do not have a Jira issue number, create one before you commit. The short summary need not be a complete sentence with proper punctuation and grammar since it is best to keep it to 72 characters or less.

After the short summary line, you may continue the message with one or more paragraphs separated by an empty line. The empty line after the short summary is necessary if you want to add more text since source control tools like git may send the log message as an email and use the first line up to an empty line as the email subject. When committing contributions from non-committers, please attribute the original author in the commit messages.

Since we support many operating systems, it would be best to list which one the commit was tested on to let the community know what has been covered.

Example Commit Log Message
TS-#### short summary (72 chars or less), not a sentence

Tested: Ubuntu-9.0.4,OSX-10.5,FreeBSD-7.2,OpenSolaris-2009.06
Author: John Doe <>

More detailed explanatory text as necessary, patch attributions, and
what platforms the commit has been tested on. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.

This is an example of a second paragraph. The 'Author:' line is required
if the commit represents code submitted by somebody who does not have
commit permissions. The person doing the commit is implicitly the
reviewer of the submitted code. The email address is optional but it
is nice to have so the original author can be uniquely identified. It 
is OK for the committer to modify or cleanup the code and if done so,
should be noted in the commit log.

In the future, I'd like to see the need for listing the operating systems tested on go away when we implement a testing environment that can accept pre-commit patch and verify that patch passes a series of smoke tests.

Commits that resolve a Jira ticket should also include an update to the CHANGES file - just add the full commit 'short summary' line and an attribution if relevant (to make it easier to view version content). Commits to this file should preserve double blank lines where they exist.


Trunk is CTR, Commit-Then-Review, policy. This was discussed and voted on by the community a long time ago. This does grant a lot of freedom to committing experimental or unstable code to the trunk. However, with such powers, comes some responsibilities:

  1. If the trunk is broken, i.e. it doesn't build and/or run even without your changes, please don't commit! No more fuel on the fire please. It should be relatively easy to track down which change set broke the build from the buildbot dashboard and inform the committer or community.
  2. You are responsible for latest trunk to build and at least start up on one of our supported platforms with your changes before you push a commit. This typically implies that you should to do a `git pull` to your tree and build before committing. Running the regression tests (trunk/ci/regression) is also highly recommended.
  3. At a minimum the the build should not break on the current primary buildbot slave which is Ubuntu Linux. If the primary build bot is broken, it is the commiter's responsibility to get the build working or find someone to help them.
  4. If your changes result in a non-functioning Traffic Server (e.g. start fails, simple forward proxy browsing is broken, etc) please consider backing out your changes and submitting the changes for review under a TS Jira ticket and asking for reviewers.

Release Branches

All release branches (e.g. 2.0.x, 3.2.X) should always be kept in a stable and functional state. The commit policy is RTC, Review Then Commit, and backporting changes from trunk should be voted on via the STATUS file on the respective branches.

  • No labels