Gluster Release process from the eyes of a release owner/wrangler:

Open and pre-open Phase:

• Ensure github project lane and milestone are created and updated with the dates
• Send release schedule and focus area mail
• Update webpage
  • https://www.gluster.org/community/roadmap/
  • https://www.gluster.org/community/release-schedule/
• Feature reminder, and close new feature acceptance by a date
  • Post closure, ensure glusterfs-specs for approved features are merged
• Dashboard to encourage review priority on release related commits
• Feature readiness posts by contributors
• Page for all release related links to be in one place/mail
  • Dashboards
  • Dates
  • etc. and refer to that in the mails

Pre-stability Phase:

• Get release milestone added in bugzilla
• Open tracking BZ for the release
• Create dashboard for merge/backport queue for release
• Branch the release (including required tagging)
  • Provide documentation by Kaushal for the same [1]
• Restrict branch merge to release owners (BZ request to infra)
• Post initial commits to,
  • Remove experimental code
  • Fixup glfs_ipc
  • max op-version
• Open up release notes commit
• Review features that made it and those that did not, and cleanup,
  • github project lane
  • Milestones in github
• Open testing issues to track closure for the release on github
• Open Documentation issues to track closure for the release
  • This comes from the main github feature issue#, so no new issue per feature, but overall file one to track and close as a release-activity
• Check if there are any major feature creeps in master post branching,
  • At times larger fixes can mask as bugs
  • At times options may have changed as a part of fixing
  • This check hence is to ensure sanity and to call out these additional changes in the release (or add it to the release scope)

Stability phase:

• Monitor fstat per week to notify list of any failures and actions needed
• Monitor backports to other LTM/STM branches and not to current release branch
• Monitor merge queue each day

Pre-release:

• Finalize release-notes and commit to branch
• Tag the branch for the release
• Start a packaging job at Jenkins for the release
  • Example: https://build.gluster.org/view/All/job/release/build?delay=0sec
• Upgrade guide added to doc site
• Release notes to doc site
• Final check on what features made it and clear up github project lane

Post-release:

• Create announcement mail
• Update blog with the announcement
• Move feature pages in glusterfs-spec to done against the release version
• Close bugs that are fixed as a part of the release
  • git log –format=email v3.10dev…v3.10.0 | grep -i ^bug: | awk '{print $2}' | sort -u > /tmp/bug-list.txt
  • close_bugs script
• Close tracking BZ for .0
• Open tracking BZ for .1
• Update webpage
  • https://www.gluster.org/community/roadmap/
  • https://www.gluster.org/community/release-schedule/
    • Update when the minor releases will happen
  • https://www.gluster.org/download/
    • Page needs an update to call out the latest release
  • https://www.gluster.org/
    • Frontpage, Gluster releases needs an update
• Close/Retire github project
• Send release retrospective
• Update ./extras/who-wrote-glusterfs/who-wrote-glusterfs.sh

Workflow to be updated:

• Update release manager responsibility for github project lane
  • http://gluster.readthedocs.io/en/latest/Contributors-Guide/GlusterFS-Release-process/
• Update developer workflow for github features
  • Maybe add a Feature handling section to http://gluster.readthedocs.io/en/latest/Contributors-Guide/Index/
• Update Patches in Gerrit section of,
  • http://gluster.readthedocs.io/en/latest/Contributors-Guide/Guidelines-For-Maintainers/
• Branching guidelines for releases needs to be posted

Scripts/automation to be closed:

• Container image building as a part of packaging

• Backup owners for packaging are needed, or some checklist there as well

• Some changes to WorkerAnt etc are needed for the github features

• Minor release

  • Check prior STM&LTM line for missing backports
    • git cherry (and compare to saved queries from past)
  • Announce mail and date
    • Sample: http://lists.gluster.org/pipermail/gluster-devel/2017-March/052435.html
    • Request for blocker bugs
  • Prepare release notes
    • NOTE: check md formatting
  • Commit release notes
  • Tag the release
  • Kick off the Jenkins job for packaging
  • Upload release notes to the doc site
  • Once packages are available,
    • Need some testing here (package installs, and possibly some basic tests)
    • Close the tracking bug
    • Mark bugs fixed in 3.10.1 as closed (run close_bugs.sh)
    • Open a new bug for the next release
    • Webpage update, blog, and ML announce
      • There should be no need to update the release pages in the website for minor releases
      • Send a mail to gluster-announce (and other lists as needed), and that will be translated into the blog post

• Things to do when retiring a release

  • Close bugs
  • Close BZ release as possible selection