Fixed backing out a backport

src/guide/jbs-jdk-bug-system.md

@@ -92,7 +92,7 @@ Note that the [Affects Version/s]{.jbs-field} field is mainly used for bugs and
 
 Set the [Affects Version/s]{.jbs-field} field to the lowest release where the bug has been seen.
 
-* The [Affects Version/s]{.jbs-field} isn't meant to be an exhaustive list of releases the issue is relevant to - it should initially be set to the release the issue was reproduced or identified on, and by implication it will be relevant to all releases past that point (see [Usage of the (Rel)[-na]{.jbs-label} Label](#usage-of-rel-na-label)). If it's later found to be applicable to an earlier release family then adding that earlier release is encouraged if the issue needs to be fixed in that release.
+* The [Affects Version/s]{.jbs-field} isn't meant to be an exhaustive list of releases the issue is relevant to - it should initially be set to the release the issue was reproduced or identified on, and by implication it will be relevant to all releases past that point (see [Usage of the (Rel)[-na]{.jbs-label} Label](#usage-of-the-rel-na-label)). If it's later found to be applicable to an earlier release family then adding that earlier release is encouraged if the issue needs to be fixed in that release.
 * Don't add additional release values to [Affects Version/s]{.jbs-field} for the same release family. For example, if there is the value [11.0.2]{.jbs-value}, don't add [11.0.5]{.jbs-value}, [11.0.7]{.jbs-value} etc. Adding an additional value for a separate release family where it's still reproducible, e.g. JDK 21, is encouraged if there isn't currently a feature release value set, or, it has been a few releases since it was last reproduced/reviewed. For example, if the [Affects Version/s]{.jbs-field} is [8]{.jbs-value}, but it is still relevant to the latest mainline release.
 * [Affects Version/s]{.jbs-field} should never use any of the "special" values available in JBS like [tbd]{.jbs-value}, [na]{.jbs-value}, [unknown]{.jbs-value}, [(Rel)-pool]{.jbs-value} or similar. Only actual JDK release numbers should be used. If you want to reflect that an issue is relevant to an older release, use a family release value or an exact release if you know where the issue was introduced: [8]{.jbs-value}, [17]{.jbs-value}, [21u4]{.jbs-value}.
 

src/guide/release-notes.md

@@ -80,6 +80,8 @@ The following are general practices that should be followed when creating releas
   * Release notes across backports
     * If an issue is backported to earlier releases the same note will be used - just add the new release version in the [Affects Version/s]{.jbs-field} field of the release note.
     * Where a different release note is required, then create a separate note with the affects version for the new release - see [JDK-8308194](https://bugs.openjdk.org/browse/JDK-8308194) and [JDK-8322473](https://bugs.openjdk.org/browse/JDK-8322473) for an example.
+  * Adding or Updating Release Notes after GA
+    * If a note needs to be added after the GA of a release, or an existing note needs updating then create the new note, or update the existing note, and then reach out to [[email protected]](mailto:[email protected]).
 
 ## RN-labels
 

src/guide/testing-the-jdk.md

@@ -310,7 +310,7 @@ There are two parts to this task, how to do the bookkeeping in JBS, and how to d
 
 ### How to work with JBS when a change is backed out
 
-#. Close the original (failed) JBS issue **(O)**.
+#. Close the original (failed) JBS issue, **(O)**.
    * "Verify" the issue with verification [Fix Failed]{.jbs-value}.
 #. If the intention is to fix the change and submit it again, create a redo-issue **(R)** to track that the work still needs to be done.
    * Clone **(O)** and add the prefix `[REDO]` on the summary - the clone becomes the redo-issue **(R)**.
@@ -319,12 +319,12 @@ There are two parts to this task, how to do the bookkeeping in JBS, and how to d
 #. Setup a backout-issue **(B)**.
    * Alternative 1 - the regression is identified directly.
      * Create a new issue of type [Bug]{.jbs-value}. This new issue will be the backout-issue **(B)**.
-     * Use the same summary as **(R)** prefixed with `[BACKOUT]`.
-     * Add a _relates to_ link between **(B)** and **(O)**.
+     * Use the same summary as **(O)** prefixed with `[BACKOUT]`.
+     * Add a _causes_ link from **(O)** to **(B)**.
    * Alternative 2 - an investigation issue was created **(I)**, and during the investigation backing out the change is identified as the best solution.
      * Use the investigation issue **(I)** for the backout. (Don't create a new **(B)**.)
      * Change summary of **(I)** to the same as **(O)** and prefix with `[BACKOUT]`.
-     * Add a _relates to_ link between **(I)** and **(O)**.
+     * Add a _causes_ link from **(O)** to **(I)**.
 #. If **(O)** had a CSR request, update the CSR issue as follows:
    * Add a _csr-for_ link from the CSR to **(R)**.
    * Add a note to the CSR that explains the reason for the redo and the impact on the CSR.
@@ -382,26 +382,25 @@ index 4961acb2126..399e7cc311f 100644
 
 ## Backing out a backport
 
-In rare cases it may be necessary to back out a backport from an update release without backing out the original fix in mainline. This will require a somewhat different procedure and will result in a small mess in JBS. It's extremely important to add comments in all relevant issues explaining exactly what's happened.
+In rare cases it may be necessary to back out a backport from an update release without backing out the original main fix. This will require a somewhat different procedure and will result in a small mess in JBS. It's extremely important to add comments in all involved issues explaining exactly what's happened.
 
 The steps to take in order to do this are described below. **(M)** used below refers to the main bug entry - the first fix that was later backported.
 
-#. Close the original (failed) JBS backport issue **(O)**.
-   * "Verify" the issue and choose "Fix Failed".
+#. Close the original (failed) JBS backport issue, **(O)**.
+   * "Verify" the issue and choose [Fix Failed]{.jbs-value}.
 #. If the intention is to fix the backport and submit it again, create a redo-issue **(R)** to track that the work still needs to be done.
    * Clone **(M)** and add the prefix `[REDO BACKPORT]` on the summary - the clone becomes the redo-issue **(R)**.
-   * Add a _relates to_ link between **(R)** and **(O)**.
+   * Add a _relates to_ link between **(O)** and **(R)**.
    * Set Fix Version of **(R)** to the target release for the backport - either the exact release if known, or `<N>-pool` if it's not critical which release the fixed backport goes into.
-#. Create a backout-issue **(B)**:
+#. Setup a backout-issue **(B)**:
    * Alternative 1 - the broken backport is identified directly.
-     * Create a sub-task to **(R)** with the same summary, but prefixed with `[BACKOUT BACKPORT]`.
-   * Alternative 2 - an investigation issue was created **(I)**, and during the investigation backing out the backport is identified as the best solution.
-     * Use the investigation issue **(I)** for the backout.
+     * Create a new issue of type [Bug]{.jbs-value}. This new issue will be the backout-issue **(B)**.
+     * Use the same summary as **(M)** prefixed with `[BACKOUT BACKPORT]`.
+     * Add a _causes_ link from **(O)** to **(B)**.
+   * Alternative 2 - an investigation issue **(I)** was created, and during the investigation backing out the backport is identified as the best solution.
+     * Use the investigation issue **(I)** for the backout. (Don't create a new **(B)**.)
      * Change summary of **(I)** to the same as **(M)** and prefix with `[BACKOUT BACKPORT]`.
-     * Move and change type of **(I)** to become a sub-task of **(R)**.
-   * Alternative 3 - no redo issue was created.
-     * Create a backout-issue **(B)** with the same summary as **(M)** and prefix with `[BACKOUT BACKPORT]`.
-     * Add a _relates to_ link between **(B)** and **(M)**.
+     * Add a _causes_ link from **(O)** to **(I)**.
 #. Add comments to **(M)**, **(R)** and **(O)** explaining the situation.
 
 The end result in JBS should look like this:
@@ -411,12 +410,12 @@ The end result in JBS should look like this:
 flowchart TD
   main("Main issue <b>(M)</b><br>JDK-8272373: Example JBS Issue<br>Issue type: Bug<br>Fix version: 18")
   backport("Initial backport <b>(O)</b><br>JDK-8280986: Example JBS Issue<br>Issue type: Backport<br>Fix version: 15.0.2<br>Verification: Fix failed")
-  backout("Backout of JDK-8280986 <b>(B)</b><br>JDK-8280996: [BACKOUT BACKPORT] Example JBS Issue<br>Issue type: Sub-task<br>Fix version: 15.0.2")
+  backout("Backout of JDK-8280986 <b>(B)</b><br>JDK-8280996: [BACKOUT BACKPORT] Example JBS Issue<br>Issue type: Bug<br>Fix version: 15.0.2")
   redo("Redo of backport <b>(R)</b><br>JDK-8280989: [REDO BACKPORT] Example JBS Issue<br>Issue type: Bug<br>Fix version: 15.0.2")
   main --> |backported by| backport
   redo --> |clones| main
+  backport --> |causes| backout
   backport <--> |relates to| redo
-  redo --> |sub-task| backout
 ~~~
 :::