[Gluster-devel] Responsiblities of a release manager

Niels de Vos ndevos at redhat.com
Wed Oct 28 11:57:59 UTC 2015


On Wed, Oct 28, 2015 at 04:17:57PM +0530, Raghavendra Talur wrote:
> 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.

We have a doc for this already, but its lost in the master branch
somewhere...

  see doc/developer-guide/GlusterFS-Release-process.md from the master
  branch in a Gerrit (not GitHub) repository. I hope that this and other
  process documents move back to readthedocs.

> 
> ======================================================================
> 
> 1. You should have inherited a tracker bug with a good alias for your
> release version, if not please create one.

This should have been done when a release is made. The tracker for the
next minor release should be created at that time.

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

Yes, something like this works. I mostly check the git repository from
the command line. There is no requirement for bugs to be listed on the
tracker bug. The ones on the tracker are most important, but others that
are not on the tracker can be fixed/merged never the less.

> 3. Create a bugzilla search for finding all dependent bugs for a release,
> something like [2]

That link does not work for me, you can not share saved bugzilla queries
easily :-/

> 4. Keep sending reminder mails on deadline approaching for merging of
> patches for the release and when tagging would be done.

Reminders to the maintainers list should be sufficient. Not sure if
there is additional value in letting the users-list know, maybe the
devel list too.

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

Yes, that is commonly done. The last commit for a release should be the
release-notes in the doc/release-notes/ directory. I do this for 3.5
like this:

  https://github.com/gluster/glusterfs/tree/release-3.5/doc/release-notes

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

Basically yes, but I mostly trust the regression tests to do the
testing. I only do some very basic tests. We really need an automated
test suite for releases, so that everyone runs the same tests.

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

Looks pretty complete to me, most of these points have been documented
already too. Please send pull requests to improve the docs :)

Thanks,
Niels


> 
> 
> [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
> ======================================================================
> 
> Thanks,
> Raghavendra Talur
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20151028/c932baa2/attachment-0001.sig>


More information about the Gluster-devel mailing list