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