loader/dri3: Add dri3_wait_for_event_locked full_sequence out parameter

[mesa.git] / docs / releasing.rst

diff --git a/docs/releasing.rst b/docs/releasing.rst
index 7a9654ac8e222c0eacddbf5c1efaac2a131d5b65..44ef53321b430866d09065f69ab9d3f7a75c556a 100644 (file)
--- a/docs/releasing.rst
+++ b/docs/releasing.rst
@@ -1,15 +1,6 @@
 Releasing Process
 =================
 
--  `Overview <#overview>`__
--  `Release schedule <#schedule>`__
--  `Cherry-pick and test <#pickntest>`__
--  `Staging branch <#stagingbranch>`__
--  `Making a branchpoint <#branch>`__
--  `Making a new release <#release>`__
--  `Announce the release <#announce>`__
--  `Update Gitlab Issues <#gitlab>`__
-
 Overview
 --------
 
@@ -36,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.
 
@@ -67,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:
@@ -76,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
@@ -170,8 +161,6 @@ Notes:
    regressions.
 -  The branch history is not stable and it **will** be rebased,
 
-.. _branch:
-
 Making a branchpoint
 --------------------
 
@@ -185,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:
 
@@ -210,8 +199,6 @@ needed. For example: files being overwritten on install, etc. Happens
 extremely rarely - we had only one case so far (see commit
 2ced8eb136528914e1bf4e000dea06a9d53c7e04).
 
-.. _release:
-
 Making a new release
 --------------------
 
@@ -223,13 +210,11 @@ Get latest source files
 Ensure the latest code is available - both in your local master and the
 relevant branch.
 
-.. _basictesting:
-
 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)
@@ -302,10 +287,15 @@ 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
+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
@@ -325,7 +315,7 @@ 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
+docs/relnotes.rst, docs/index.rst, and docs/release-calendar.rst. It
 will then generate a git commit automatically. Check that everything
 looks correct and push:
 
@@ -333,8 +323,6 @@ looks correct and push:
 
       git push origin master X.Y
 
-.. _announce:
-
 Announce the release
 --------------------
 
@@ -343,12 +331,10 @@ Use the generated template during the releasing process.
 Again, pay attention to add a note to warn about a final release in a
 series, if that is the case.
 
-.. _gitlab:
-
 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.