Brief form of Release Team Tasks

This document is here merely to serve as a fast reminder of what tasks need to be done and when they need to be done relative to major milestones in the release. See Release Team Tasks for a thorough description of the tasks that need to be done and the milestones in a release and the current unstable release schedule for the actual dates of the milestones for the current release cycle.

A note for all community members: We all tend to have pretty full plates and might forget about deadlines from time to time. If you see us slip and miss any of the tasks on this list by more than two days past the specified time, feel free to email us at release-team@gnome.org to remind us. Tasks by milestone

• After a major release
  • Send out a reminder to devel-announce-list that the hard code freeze is over but other freezes remain in effect; also remind about branching policy (so that all maintainers remember to notify all relevant mailing lists)
  • Put together the release schedule for the next release (tools for this are in git's releng/tools/schedule); try to get it up at www.gnome.org/start/unstable (in git that is static-web/tree/calendars/schedule-unstable.ics) within a week (people need to know when the next stable minor releases are in advance); announce draft and final schedule to devel-announce-list and distributor-list
  • Announce start of module/feature proposal period
  • Have a meeting to define release assignments; add them to the schedule file in git's releng/tools/schedule (for mail reminders to release-team mailing list)
• For each release
  • Send out call for tarballs to devel-announce-list two days before release.
  • Watch ftp.gnome.org and nag maintainers who haven't released.
  • Send out an announcement of the release to gnome-announce-list and www.gnomedesktop.org at 12:00 UTC the day of the release.
• For each freeze
  • Send out a reminder about the freeze a week in advance to devel-announce-list.
• For feature freeze
  • Get consensus on new modules.
  • Get consensus on any system wide change if there are any proposed (e.g. default theme change), send out a call for a new splashscreen.
• Each Beta and release candidate
  • Remind bugsquad to provide a list of potential showstopper bugs, possibly remove any bugs that don't belong on the list, and then send the result to devel-announce-list.
• Beta 1
  • Contact the various teams (accessibility, documentation, translation, usability, etc.) for a status update
• Release Candidate 1
  • Find volunteers from the community to put together the release notes. Work with this team to provide feedback and important information that needs to be included.
• Periodically watch out for
  • modules with an unusually large number of bugs, or bugs with unusually high impact (potential showstopper buglist from the bugsquad may help with this)
  • unannounced freeze breaks
  • modules being unmaintained or undermaintained