Policy for Integration in a Long Term Updates branch of GLib and GTK+

This document is a draft

Pre-requisites for integration

• Each patch needs a bug report.

  • There is no exception for this rule.
  • Bug reports allow tracking progress, reviews, and provide accountability through a paper trail. The same bug report can be used for a set of patches, but each patch must reference the bug report that it closes in its commit message.
  • Patches "approved on IRC" are not acceptable.
  • The mailing list is an acceptable substitute to Bugzilla, but only for notifications and discussions: patches should still be attached to Bugzilla.

• Each patch needs to pass the test suite.

  • The whole test suite needs to pass.

• A patch must not introduce compiler warnings.

  • Compilation with a strict set of CFLAGS is mandatory; using -Werror is preferred. Patches that result in compiler errors on different platforms are not acceptable.

• One issue per patch.

  • A patch must not fix more than one issue, be it related or (worse) unrelated.

• No new features. No new API. No deprecations. No large refactorings.

  • The behaviour and results of GLib and GTK+ must not change. Patches that change the visual aspect of GTK+ are not acceptable.
  • Documentation patches are acceptable, as long as they refer to markup fixes, clarifications, or corrections of factual errors.
  • Patches that fix the implementation of platform-specific code are acceptable; patches that change the implementation on different architectures or operating systems are not acceptable.
  • Patches that add new warnings are not acceptable.

• No regressions.

  • Each patch should be tested under a full GNOME session.
  • If a patch touches GDK backend code, it should be tested with different backends.
  • Patches that fix regressions with previous stable releases are acceptable.
  • Patches that introduce performance regressions are not acceptable.

• No dependencies updates.

  • Patches that change the required minimum version of the dependencies are not acceptable.

Steps

• Identify a patch meant for integration in the long term updates branch.
  • If the patch is already attached to a bug, then:
    • add a comment requesting integration and verifying that the patch has been tested;

    • add gtk-stable@gnome.bugs to the CC list.

  • If the patch is new, then:
    • open a bug for the patch;
    • follow the same process outlined above.
• Only the maintainer of the long term updates branch is allowed to commit the patch to the long term updates branch.
  • Unless the maintainer gives the go ahead on Bugzilla.
  • Commits without prior approval will be reverted.
• Releases from the long term updates branch should contain a minimal amount of changes.