Gwibber Project Policies

Release Schedule

Gwibber will follow GNOME's release schedule and version scheme.

PPA

There is a daily PPA built from trunk for testing.

Trunk Stability

• Trunk should always remain buildable.
• Trunk should always pass the test suite.
• Any tagged release in trunk should correspond to a released tarball and be especially stable and coherent.

Code Reviews

All non-trivial branches need a code review.

Examples of trivial branches:

• translation updates
• test updates (new passing tests or fixups for existing tests)
• documentation fixes
• version bumps
• build system changes

Examples of non-trivial branches:

• normal bug fixes
• features
• refactors

Review Flow

1. A branch will be flagged as ready-for-review in Launchpad for merging into trunk by developer A.

2. A separate member of ~gwibber-committers -- developer B -- will review the branch.

3. Once approved, developer A will merge into trunk if able. Else developer B will.

Review Requirements

1. All new tests must include tests for both python and vala
2. Any changes to tests must include corrisponding changes in both python and vala
3. Bug fixes and feature branches for libgwibber and libgwibber-gtk must include tests
   • Note: Bug fixes for high or critical bugs in code that doesn't already have the necessary framework in place for testing can be allowed without tests, but ensure maximum manual testing of the fix. Lower priority bug fixes should include new tests as well as the test framework necessary to run them. This is just until we get more test coverage of the libraries.

Feature Approval

All branches that introduce features or important UI changes additionally need approval from a member of ~gwibber-team. This sign-off may implicitly come from either developer A or B above or explicitly from a third party C during the code review.