Release Team Tasks

The Release Team collectively has responsibility for the following tasks.

General Responsibilities

The Release Team has overall responsibility for delivery of GNOME's software. This includes having high-level control over release processes, quality control, and project-wide technical coordination. The Release Team also sets policies for which software makes up GNOME, as well as dependencies and portability.

Regular Tasks

• Creating the schedule for the development cycle.
• Defining and maintaining the module list for each moduleset.

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

• Reviewing freeze break requests.
• Tracking blocker bugs in the run up to each release.
• Checking, making, and announcing releases.

One-Time Tasks

Modulesets

• fredp: clean up moduleset categories. Use them consistently across GNOME infrastructure.

  • Thread about this: https://mail.gnome.org/archives/release-team/2014-August/msg00065.html

  • Draft documentation ( https://wiki.gnome.org/AllanDay/Modulesets ) needs to be integrated into other wiki pages.

• olav: api.gnome.org needs update (api-web git module) - currently manual syncing between those infrastructure tools
• olav: create pre-commit check on doap files (in sysadmin git module)

• no owner: document what we expect from external dependencies and how to add new ones. should go on or be referenced by https://wiki.gnome.org/MaintainersCorner

• fredp: automate mailing changes that happens in the modulesets (new deps...)

Release Team Working

• everyone: Document what release team commits to. eg. blocker bugs.
• andre: put regular r-t meetings into schedule. maybe invite others e.g. 1 from qa/design. figure out what makes sense (formal representation?)

• everyone write up what they do on the release team for the last 6 months in https://wiki.gnome.org/ReleasePlanning/ReleaseTeamGroup [KjartanMaraas and LucaFerretti are outstanding.]

• fredp: check (and update) - https://wiki.gnome.org/ReleasePlanning/MakingARelease

• andre: finish https://wiki.gnome.org/AndreKlapper/ReleasePlanningTimeline (and look into breaking down tasks in more detail so interested folks might be able to help or automate things

Release Schedule

• andre: .0 release meeting reflection: add agenda item to reflect on what r-t members did last cycle
• andre: add regular r-t tasks to schedule. e.g. sending of blocker bugs
• andre: split schedule maybe into public and private?
• fredp: add deprecation check of existing modules to the schedule
• ove the start of the period at the time of "The Freeze" [aday: what's the background to this?]
• olav: change wiki schedule ui (isocalweek, day of week+day of month)

Other

• no owner: require contingency plans for feature pages. add this to the template
• olav: discuss with gnome-continuous to change gnome git workflow. maybe have gnome-continuous tag known working versions. have jhbuild point to known working versions by default, then people working with jhbuild need to specify which modules you're actually working on, for the rest just take known working versions

• Release process changes:

  • Feature proposals become non-binding - RT approval isn't required.
  • Start tracking target/blocker bugs at the beginning of each cycle, and review regularly.
  • Only RT can make moduleset changes. Change requests must be sent to d-d-l.