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.


  • 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.

EmmanueleBassi/LongTermUpdates (last edited 2013-01-04 14:04:33 by EmmanueleBassi)