1. You should have inherited a tracker bug with a good alias for your release version, if not please create one. 2. Use gerrit search something like [1] to find all the patches that were merged after previous release and ensure that the bugs they are using are already added to depends-on list of tracker bug. 3. Create a bugzilla search for finding all dependent bugs for a release, something like [2] 4. Check backports requests from [3] 5. Keep sending reminder mails on deadline approaching for merging of patches for the release and when tagging would be done. QUESTION: Should we start making a commit along with a tag for a release where the commit updates a RELEASE-NOTES file in the repo with the same content as that would go later in the release announcement mails? 6. On hitting deadline, send a mail informing of a temporary hold on merging of patches and start testing the branch comprehensively. Once sufficiently tested, make a tarball and ask the build team to make builds for various distributions. 7. Announce the release on mailing list, blogs etc with links to packages to be downloaded. Make sure you document all user facing changes and provide a list of bugs fixed. 8. Use a script to mark all the depends-on bugs that were merged as closed and fixed in the release version. 9. Create a tracker bug for next release in the same branch and move all the depends-on bugs that were not merged to the next release. [1] https://review.gluster.org/#/q/project:glusterfs+branch:release-3.7+status:merged+after:2015-10-07 [2] https://bugzilla.redhat.com/buglist.cgi?cmdtype=runnamed&list_id=4043168&namedcmd=glusterfs-3.7.6-depends-on [3] https://public.pad.fsfe.org/p/gluster-backport-requests ====================================================================== _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
