Governance/Rejected/ProjectToolingAndPractices

Project Tooling and Practices

The OpenStack community produces a coherent, integrated set of cloud software from a number of independent, but cooperating projects. Projects should use common frameworks, tools, policies and practices whenever possible to encourage a cohesive community and a common experience for developers and users. This also reduces the number of divergent toolsets that the community is required to maintain. By default, projects should use existing tools and practices unless they have a need for which there is no existing option or there is a compelling need to use something different. In such cases, the PPB may grant an exception or expand the set of existing options to meet the project's need.

For common tools and practices, the PPB can define a vetted set of options from which projects may choose. New options can be proposed to the PPB for consideration. The PPB should solicit feedback from members of the community who would be impacted by the proposal and provide adequate time for community members to review the proposed tool or practice. Below is a list of some of the existing tools and practices.

Source Code Management

Source code for every project should be managed through a version control system to track changes and enable development among distributed teams of developers.

Vetted Options:<
> Launchpad/Bazaar

Release Management

Releases should be managed through a system that allows effective tracking of the changes and major features within a release. This information should be easily published for use by the many non-developers who follow OpenStack for deployment purposes or for integration into 3rd party projects and products.

Vetted Options:<
> Launchpad

Issue Tracking

Projects should have a public issue tracking repository that allows users and developers to submit bugs, improvements and feature requests and track the status of existing issues. Ideally the Issue Tracking system will integrate with the Source Code Management system to provide linking between an issue and the code changes that are relevant to it.

Vetted Options:<
> Launchpad

Contribution Merging

Contributed code changes should be reviewed before being accepted into official project source trees for quality, functionality and adherence to coding standards. A gating mechanism should be present in each project to guarantee that source code contributions are not merged until this review process has been completed.

Vetted Options:<
> Launchpad

Release Timing

OpenStack will make an integrated release of all core projects every 6 months. This release will include more extensive testing, especially surrounding the interaction between each project.

In between releases, projects will release milestones that are project specific and do not have guaranteed compatibility with other projects. This milestones may include new features or bug fixes and may be released according to either a timed-release process or feature release process at the discretion of the PTL.

Core projects should coordinate releases and milestones with the Release Manager.

---