Tacker Development Process

Tacker Development Process

Contributing

The best way to join the community and get involved is to talk with others online or at a meetup and offer contributions. Here are some of the many ways you can contribute to the Tacker project:

  • Development and Code Reviews
  • Bug reporting/Bug fixes
  • Wiki and Documentation
  • Blueprints/Specifications
  • Testing
  • Deployment scripts

Before you start contributing take a look at the Openstack Developers Guide.

Freenode IRC (Chat)

You can find tacker guys in our publicly accessible channel on freenode #tacker. All conversations are logged and stored for your convenience at eavesdrop.openstack.org. For more information regarding OpenStack IRC channels please visit the OpenStack IRC Wiki.

Launchpad

Like other OpenStack related projects, we utilize Launchpad for our bug and release tracking.

Note

Bugs should be filed on Launchpad, not Github.

Source Repository

The offical Tacker source code is available in following repositories:

The mirror repositories on Github:

Gerrit

Like other OpenStack related projects, we utilize the OpenStack Gerrit review system for all code reviews. If you’re unfamiliar with using the OpenStack Gerrit review system, please review the Gerrit Workflow wiki documentation.

Note

Pull requests submitted through GitHub will be ignored.

Enhancement to Tacker functionality can be done using one of the following two development process options. The choice depends on the complexity of the enhancement.

Request for Enhancement (RFE) Process

The developer, or an operator, can write up the requested enhancement in a Tacker launchpad [1] bug.

  • The requester need to mark the bug with “RFE” tag.
  • The bug will be in the initial “New” state.
  • The requester and team will have a discussion on the enhancement in the launchpad bug.
  • Once the discussion is over a tacker-core team member will acknowledge the validity of this feature enhancement by moving it to the “Confirmed” state.
  • Developers submit patchsets to implement the enhancement using the bug-id. Note, if there are multiple patchsets Partial-Bug header should be used instead of Closes-Bug in the commit message.
  • Once all the patchsets are merged the bug will be moved to the “Completed” state.
  • Developer(s) are expected to add a devref describing the usage of the feature and other related topics in tacker/doc/source/contributor directory.

This process is recommended for smaller enhancements that can be described easily and it is relatively easy to implement in a short period of time.

Blueprint and Tacker-Specs process

The developer, or an operator, can write up the requested enhancement by submitting a patchset to the tacker-spec repository [2].

  • The patchset should follow the template specified in [3]
  • The requester should also create a corresponding blueprint for the enhancement proposal in launchpad [4]
  • The requester and the team will have a discussion on the tacker-spec writeup using gerrit.
  • The patchset will be merged into the tackers-specs repository if the tacker-core team decides this is a valid feature enhancement. A patchset may also be rejected with clear reasoning.
  • Tacker core team will also mark the blueprint Definition field to Approved.
  • Developer submits one or more patchsets to implement the enhancement. The commit message should use “Implements: blueprint <blueprint-name>” using the same name as the blueprint name.
  • Once all the patchsets are merged the blueprint will be as “Implemented” by the tacker core team.
  • The developer is expected to add a devref describing the usage of the feature and other related topics in tacker/doc/source/contributor directory.

This process is recommended for medium to large enhancements that needs significant code-changes (LOC), community discussions and debates.

Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.