Hi,
Here is a list that I could come up with while researching on responsibilities of a release manager.
I request inputs from more people to make it more comprehensive and correct so that we can put it up in docs and point new release managers to it.
======================================================================
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. 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?
5. 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.
6. 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.
7. Use a script to mark all the depends-on bugs that were merged as closed and fixed in the release version.
8. 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.
======================================================================
Thanks,
Raghavendra Talur
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
