Release Team Tasks

You should basically count on this page being out-of-date. We have not been able to keep it up to date with task assignments and sometimes even with which tasks even exist. It might still have something useful in it, so we're not deleting it.

(See also http://developer.gnome.org/dotplan/tasks.html)

The Release Team should take care of at least the following tasks:

One person should have responsibility for the official completion of these tasks, though the whole team and whole community should be involved as much as possible. And some tasks (such as release notes) should be delegated completely to other teams, with a release team person just checking that it gets done. The first name listed is the owner; the owner can contact the other people listed for help.

See also Tasks By Time.

General

Essential

• Creating a schedule for the development cycle (Elijah if no one else wants it)

  • email it to devel-announce
  • post on wiki, footnotes

  • (ideally) post as an ical file for evo

• Reminding maintainers that tarballs are due & remind about freezes.

  • (VincentUntz, JohnPalmieri)

• Checking, making, and announcing releases.

  • (VincentUntz, Elijah Newren, JohnPalmieri)

• Defining the module list for each release set (VincentUntz, LuisVilla4)

  • Call for new modules.
  • Encouraging a new modules discussion in the community.
  • Announcing new modules decision.

• Approving/rejecting freeze breaks (This is too much for one person. There are usually 3 or 4 technical release-team people who do this.)

  • (VincentUntz, Elijah Newren, JohnPalmieri, KjartanMaraas, FredericCrozat)

• Ensuring release notes get written (delegate to GnomeMarketing)

  • (???)

Additional

• We encourage discussion about new functionality and API that the developers would like to implement. We try to list these as general suggestions for developers to work on, in the Road Map but it is understood that the functionality will actually be ready when it is ready, and subject to the release schedule.

• String bugs nagging (before string freeze): push maintainers to fix as many l10n/i18n bugs as possible by providing them with nice reports. (Delegate to i18n team)
  • What kind of reports do you want? If these are bugzilla reports, I (Elijah Newren) could help with creating them.

• Patch-review nagging (Delegate AndreKlapper, Elijah Newren)

• Showstopper bugs nagging (Delegate to AndreKlapper, Elijah Newren)

• Monitoring quality
  • The release team tries to monitor development and judge its quality and stability. We try to remind developers of the schedule and alert them to particular problems that might need their attention. We watch out particularly for:
    • Modules with unusually large numbers of bugs, or bugs with unusually high impact.
    • Unannounced freeze breaks.
    In extreme cases, the release team can request that a particular feature be reverted to a previous version. This might even mean that a whole module must be reverted to a previous version. This is only likely to be considered during the last, scary, weeks of the release schedule. So far it has never actually happened.

Bindings Suite

Desktop Suite

• UI review happens (before UI freeze): make sure one happens. (Delegate to UI-review team)

Platform Suite

Potential tasks

• a11y bugs nagging. (Delegate to accessibility-list)
• make sure that the help buttons open help at the right place before the .0 release. (Delegate to gnome-docs team)