GNOME Release Planning Timeline

An attempt to cover recurring r-t tasks in the release cycle. Feel free to add tasks.

NOTE: To merge with https://live.gnome.org/ReleasePlanning/Tasks/ByTime that I could not find when I created this.

To merge/move under https://live.gnome.org/ReleasePlanning once a full release cycle is covered.

About eight weeks before stable major:

• Make sure that gnome-i18n and gnome-doc-list know about new modules/applications planned to get into the next release (for 3.2, it was unknown for a too long time that e.g. sushi, gnome-documents and gnome-contacts are expected to be shipped by default)

About four/five weeks before stable major:

• Start writing the release-notes, contact marketing for this

• Send blocker bugs review (bug reports with "GNOME Target" field set) to d-d-l

  • Add mailing list archive URL to "Last Reviews" afterwards

• Shortly before string freeze it might be good to have reviews of translatable strings in new modules, and check for common mistakes (e.g. Plural handling by checking strings with %d's) in existing ones, and for strings not marked for translation (see https://bugzilla.gnome.org/show_bug.cgi?id=660600#c0 and/or use intltool-update -m )

About two weeks before stable major:

• Send another blocker bugs review to d-d-l

  • Add mailing list archive URL to "Last Reviews" afterwards

• Create https://live.gnome.org/ThreePointFive (replace URL by corresponding name of next development cycle)

• Create https://live.gnome.org/ThreePointFive/Features (replace URL by corresponding name of next development cycle)

• Clean up RoadMap for the next release cycle

• Write schedule draft for next release cycle:
  • Create /releng/tools/schedule/x.y.schedule file in git
  • Use scripts in /releng/tools/schedule in git and replace any values with the old version (e.g. "3.2") by the new one (e.g. "3.4")
  • Publish on a non-official page on the wiki

  • Ask release-team for feedback

• Check for broken xml in documentation translations: https://mail.gnome.org/archives/gnome-i18n/2010-October/msg00112.html

A few days before hardcode freeze:

• Send list of bug reports with patches with status accepted_commit_now to d-d-l (3.1 example)

• Announce feature proposal period on d-a-l (3.3 example, 3.5 example)

• After r-t feedback, announce schedule draft for next release cycle (3.3 example) on d-d-l (3.3 example)

• Update/upload schedule ics file: git checkout releng, go to tools/schedule/, run ical.py after setting DEFAULT_SCHEDULE in libschedule.py to "3.6.schedule", and after testing locally in Evolution's calendar upload the output to Infrastructure/static-web//calendars/schedule-unstable.ics

Under hardcode freeze:

• Review break request like mad.
• Sort out if anybody will provide live images

Directly before major release:

Sync with marketing: https://live.gnome.org/GnomeMarketing/ReleasePlanning

After major release:

• Add moduleset definitions for next version to jhbuild (3.3 example)

• Update the redirect of https://www.gnome.org/start/unstable (example, sysadmin territory)

• Update links with version numbers on https://live.gnome.org/ReleasePlanning

• Update version numbers on https://live.gnome.org/Schedule

• Finalize schedule draft:

  • Remove "draft" warning on the wiki (3.5 example)

  • Announce it on d-a-l (3.5 example)

  • Go to your git checkout of releng/tools/schedule
  • Make sure DEFAULT_SCHEDULE in libschedule.py is set to "3.6.schedule"

  • Run "./ical.py > 3.6.ics" to create the calendar file

  • Import the 3.6.ics file in Evolution to check if all went well

  • git add/commit/push the 3.6.ics file to the releng git module (3.5 example)

  • Copy ics file to Infrastructure/static-web git module into the calendars folder and git commit/push it (3.33 example)

• Send list of bug reports with patches with status accepted_commit_after_freeze to d-d-l

After Feature proposal freeze:

• r-t meeting to discuss proposals (3.3 example of feature proposals)

  • After any meeting: Update https://live.gnome.org/ReleasePlanning/Meetings with link to meeting minutes

After .2 release:

• Bump the minimum required GNOME version for bug reports submitted to GNOME Bugzilla via bug-buddy to previous-major.0 and announce it on gnome-bugsquad.