[Gluster-devel] Responsiblities of a release manager (updated)

Kaleb KEITHLEY kkeithle at redhat.com
Wed Nov 25 13:52:12 UTC 2015


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
======================================================================


More information about the Gluster-devel mailing list