Clutter Wiki

Views
From ClutterProject
Jump to: navigation, search

Policies of the Git repositories

The Git repository for Clutter and its related projects come with some policies, which are intended to avoid shooting ourselves in the foot.

  • Bindings go under the bindings/ sub-project
  • Features are developed under topic branches
    • The common naming policy for topic branches is: branch-name or developer/branch-name
    • If the branch is published but might be rebased because it's still a work in progress, then the name should include 'wip', e.g.: wip/branch-name
  • Topic branches should strive to have a clean merge
  • Thou shalt not break master - The master branch should always compile, and possibly pass the conformance test suite
  • Thou shalt not break git bisect - make sure that every commit compiles, and possibly passes the conformance test suite

Development of Core

This policy is still a work in progress: the Clutter development team might drop it at any later date, if we find we cannot sustain it.

We should strive for a Core repository that's mostly clean, bisectable and working. In theory, the least amount of people should have commit rights on the Core repository.

Development of components under Core should be done in topic branches or separate, per-developer tree - possibly on clutter-project.org, but other services are perfectly acceptable. The release manager for each development cycle should be the responsible of merging the separate trees and branches during the development window.

Merge window for developers snapshots: Each snapshot is released on Mondays. The merge window for each development snapshot is open starting the Wednesday before the release.

Merge window for stable releases: Stable releases are done on Mondays. The merge window for each stable release is open starting the Friday before the release.

Personal tools