pipebuffer: Remove unused buffer event in slab bufmgr

[mesa.git] / docs / releasing.rst

diff --git a/docs/releasing.rst b/docs/releasing.rst
index 47b4686959b112b447de663f51f477571c8d8419..dbaa0e17afb6ccfd93c6671f545b5b8593723b63 100644 (file)
--- a/docs/releasing.rst
+++ b/docs/releasing.rst
@@ -27,7 +27,7 @@ Release schedule
 Releases should happen on Wednesdays. Delays can occur although those
 should be kept to a minimum.
 
-See our `calendar <release-calendar.html>`__ for information about how
+See our :doc:`calendar <release-calendar>` for information about how
 the release schedule is planned, and the date and other details for
 individual releases.
 
@@ -58,7 +58,7 @@ Stable releases
    This also involves that, as a final release may be delayed due to the
    need of additional candidates to solve some blocking regression(s), the
    release manager might have to update the
-   `calendar <release-calendar.html>`__ with additional bug fix releases of
+   :doc:`calendar <release-calendar>` with additional bug fix releases of
    the current stable branch.
 
 .. _pickntest:
@@ -67,7 +67,7 @@ Cherry-picking and testing
 --------------------------
 
 Commits nominated for the active branch are picked as based on the
-`criteria <submittingpatches.html#criteria>`__ as described in the same
+:ref:`criteria <criteria>` as described in the same
 section.
 
 Nominations happen via special tags in the commit messages, and via
@@ -174,7 +174,7 @@ to stabilisation and bugfixing.
    should be tackled already.
 
 Check if the version number is going to remain as, alternatively
-``git mv docs/relnotes/{current,new}.html`` as appropriate.
+``git mv docs/relnotes/{current,new}.rst`` as appropriate.
 
 To setup the branchpoint:
 
@@ -214,7 +214,7 @@ Perform basic testing
 ~~~~~~~~~~~~~~~~~~~~~
 
 Most of the testing should already be done during the
-`cherry-pick <#pickntest>`__ So we do a quick 'touch test'
+:ref:`cherry-pick <pickntest>` So we do a quick 'touch test'
 
 -  meson dist
 -  scons (from release tarball)
@@ -261,18 +261,13 @@ Create release notes for the new release
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The release notes are completely generated by the
-``bin/gen_release_notes.py`` script. Simply run this script before
-bumping the version, and commit the results. The only thing left to do
-is add the sha256 sums.
+``bin/gen_release_notes.py`` script. Simply run this script **before**
+bumping the version. You'll need to come back to this file once the
+tarball is generated to add its ``sha256sum``.
 
-Increment the version contained in the file VERSION at Mesa's top-level,
-then commit this change.
-
-Commit these changes and push the branch.
-
-::
-
-   git push origin HEAD
+Increment the version contained in the file ``VERSION`` at Mesa's top-level,
+then commit this change and **push the branch** (if you forget to do
+this, ``release.sh`` below will fail).
 
 Use the release.sh script from xorg `util-modular <https://cgit.freedesktop.org/xorg/util/modular/>`__
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -287,11 +282,16 @@ Pay close attention to the prompts as you might be required to enter
 your GPG and SSH passphrase(s) to sign and upload the files,
 respectively.
 
+Ensure that you do sign the tarballs, that your key is mentioned in the
+release notes, and is published in `release-maintainers-keys.asc
+<release-maintainers-keys.asc>`__.
+
+
 Add the sha256sums to the release notes
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Edit docs/relnotes/X.Y.Z.html to add the sha256sum as available in the
-mesa-X.Y.Z.announce template. Commit this change.
+Edit ``docs/relnotes/X.Y.Z.rst`` to add the ``sha256sum`` as available in the
+``mesa-X.Y.Z.announce`` template. Commit this change.
 
 Back on mesa master, add the new release notes into the tree
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -309,10 +309,10 @@ Then run the
 
    ./bin/post_version.py X.Y.Z
 
-, where X.Y.Z is the version you just made. This will updated
-docs/relnotes.html, docs/index.html, and docs/release-calendar.html. It
-will then generate a git commit automatically. Check that everything
-looks correct and push:
+, where X.Y.Z is the version you just made. This will update
+docs/relnotes.rst and docs/release-calendar.rst. It will then generate
+a git commit automatically. Check that everything looks correct and
+push:
 
 ::
 
@@ -329,7 +329,7 @@ series, if that is the case.
 Update gitlab issues
 --------------------
 
-Parse through the bug reports as listed in the docs/relnotes/X.Y.Z.html
+Parse through the bug reports as listed in the docs/relnotes/X.Y.Z.rst
 document. If there's outstanding action, close the bug referencing the
 commit ID which addresses the bug and mention the Mesa version that has
 the fix.