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)

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 )

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

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

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

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

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.