• git clone (or git fetch to get the latest stable branch updates). Do not checkout the release branch as it does not have the ceph-release-notes script
  • run the following:
    cd ceph/src/script
    virtualenv v
    source v/bin/activate
    pip install githubpy GitPython review requests
    GITHUB_ACCESS_TOKEN=XXXXXXXXXXXXXX ./ceph-release-notes --strict -r tags/v9.2.1..origin/infernalis $(git rev-parse --show-toplevel)
  • The ceph-release-notes script requires that each pull request is prefixed with the component it relates to (mon, osd etc.). If that's not the case, it will display an error message such as
    ERROR: title Keystone PKI token expiration is not enforced does not match ^(?:hammer|infernalis|jewel|kraken): (cli|common|mon|osd|fs|librbd|rbd|fs|mds|objecter|rgw|build/ops|tests|tools|cmake|doc|crush|librados)(:.*)

    the pull request title must be edited to add the required prefix.
  • add a section in in the master branch of ceph in the release-notes.rst file with the list of commits. The general idea is that the file on master reflects all releases ever published. The relevant part is then backported so that it also shows in the stable branch.
  • create a pull request with this change and assign it to the Ceph lead
  • add the text only version of the release notes as a comment to the pull request
    GITHUB_ACCESS_TOKEN=XXXXXXXXXXXXXX ceph-release-notes --text --strict -r tags/v9.2.1..origin/infernalis $(git rev-parse --show-toplevel)

    so that it can conveniently be copy/pasted when sending the mail announcing the release.
  • backport the release notes to the release branch when they are final. Ideally this is done before the point release is published. If not it can be backported shortly afterwards.
  • add the release to the timeline
  • the release notes come with an introduction that is prepared in a separate file . It can be edited if something significant must not be forgotten and it does not need to well written because it is a draft.
  • the content of the pending release notes file can be manually added at the beginning of the release-notes.rst. In theory the person writing the release notes should know about these pending notes so this is just a way to make sure they are not forgotten.