Apache Process (Links)

Bugs

  • Traffic Server uses GitHub
  • Bugs should be created for any task or bug that needs to be done to the code base
  • If there is an issue, added the issue number in the pull request comment
  • Assign the bug you are working on to yourself
  • Close bugs after they are tested and checked in, so we can track progress
  • Bugs should be assigned a release if it is known what release it will be in

Building and Packaging

Coding

Coverity

  • Coverity is one of the static code analysers we run on Traffic Server to find problems in the code. You might see comments like this in the code:

        // coverity[secure_coding]
    if (sscanf(buf, "%d\n", &val) != 1) {

    This means not to report on the error in the following line of code. If you are going to modify the code on the following line or want to remove the comment please ask someone with some experience with Coverity. There are more details on various Coverity features and interaction in the Documentations page.

Version Control

  • GitHub - Apache Traffic Server uses git exclusively

Versioning

  • We will be using major.minor.patch format for versioning releases
  • major will be for binary compatibility
  • minor will be for new features
  • patch will be for bug fixes on a patch release

Backports

Bugs which are fixed in master (trunk) can be backported to stable series releases. This should be for critical fixes, crashes or security issues. With our frequent releases, we no longer expect to cherry-pick and release features or other non-critical fixes to stable release branches. While everyone can suggest patches to be back ported, only the current release manager is doing the actually back port commit on a release branch. The process for backporting a JIRA to one (or several) release branches is

  1. Commit the fix to master as usual, make sure it builds, runs and tests properly.
  2. Close the JIRA as normal.
  3. Mark the bug with a "Backport" tag to the branch release (or releases) that you believe is appropriate. This can be done by anyone, not just the person(s) who initially made the fixes. Leave the JIRA close though.
  4. The RMs will take the backport suggestions into suggestions.

If a RM decides a Backport is appropriate, the following steps happens:

  1. The JIRA is reopened.
  2. Once the commit(s) have been cherry picked to a release branch, the Backport tag is removed (or updated) accordingly, and the "Fix Version" tag is updated. This means the "Fix Version" now contains two or more version numbers. This is as expected, and helps us keep track on which versions a fix is going in for.
  3. The JIRA is once again closed.

 

  • No labels