Conversation
|
👋 Welcome back jwilhelm! A progress list of the required criteria for merging this PR into |
|
@JesperIRL This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be: You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been no new commits pushed to the ➡️ To integrate this PR with the above commit message to the |
Webrevs
|
Co-authored-by: Alexey Ivanov <alexey.ivanov@oracle.com>
| Most resolutions are used to close an issue so that it ends up being [Closed]{.jbs-value} directly, but resolutions that indicates that a change has been integrated into a Project repository must go through the [Resolved]{.jbs-value} state. An issue in [Resolved]{.jbs-value} state needs to go through [verification](#verifying-an-issue) to end up as [Closed]{.jbs-value}. For the JDK Project in almost all cases the bots will transition the issue to [Resolved]{.jbs-value}/[Fixed]{.jbs-value} when the changeset is integrated to the repository. | ||
| When a change is integrated into a project repository, the corresponding JBS issue should be [Resolved]{.jbs-value} with the resolution [Fixed]{.jbs-value}. For the JDK Project, in almost all cases the bots will transition the issue to [Resolved]{.jbs-value}/[Fixed]{.jbs-value} automatically when the changeset is integrated. There are a few more cases where you want to indicate that a change has been integrated into a project repository that must also go through the [Resolved]{.jbs-value} state. In other cases, where you close an issue manually, it should go directly to [Closed]{.jbs-value} with the appropriate resolution. See the [table below](#close-resolve-table) for more details. | ||
|
|
||
| An issue in [Resolved]{.jbs-value} state needs to go through [verification](#verifying-an-issue) to end up as [Closed]{.jbs-value}. If you accidentally move an issue to the [Resolved]{.jbs-value} state for a resolution that should only be [Closed]{.jbs-value}, use the "Verify" option in the state transition menu and select verification [None]{.jbs-value}. |
There was a problem hiding this comment.
I'm still confused as to what version of the suggestion you liked best.
| An issue in [Resolved]{.jbs-value} state needs to go through [verification](#verifying-an-issue) to end up as [Closed]{.jbs-value}. If you accidentally move an issue to the [Resolved]{.jbs-value} state for a resolution that should only be [Closed]{.jbs-value}, use the "Verify" option in the state transition menu and select verification [None]{.jbs-value}. | |
| An issue in the [Resolved]{.jbs-value} state needs to go through [verification](#verifying-an-issue) to end up as [Closed]{.jbs-value}. If you move an issue to [Resolved]{.jbs-value} when it should be [Closed]{.jbs-value}, use the "Verify" option in the state transition menu and select verification [None]{.jbs-value}. |
I think my second suggestion was clearer. I reverted to “move” instead of “transition” to avoid confusion with “state transition menu”; although they're closely related, and perhaps using the same word is better.
Added missing info about components when filing a JBS issue
Also clarified how to close a resolved issue through verification
Progress
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/guide.git pull/169/head:pull/169$ git checkout pull/169Update a local copy of the PR:
$ git checkout pull/169$ git pull https://git.openjdk.org/guide.git pull/169/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 169View PR using the GUI difftool:
$ git pr show -t 169Using diff file
Download this PR as a diff file:
https://git.openjdk.org/guide/pull/169.diff
Using Webrev
Link to Webrev Comment