-
Notifications
You must be signed in to change notification settings - Fork 29
Select component when filing issue #169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
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 |
| Once the work on an issue has been completed the issue's [Status]{.jbs-field} should be in a "completed" state. There are two "completed" states: [Resolved]{.jbs-value} and [Closed]{.jbs-value}. These are accompanied by a [Resolution]{.jbs-field} and a [Fix Version/s]{.jbs-value}. Which combination of [Status]{.jbs-field}, [Resolution]{.jbs-field}, and [Fix Version/s]{.jbs-value} you should use depends on how the issue is completed. | ||
|
|
||
| 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. | ||
| 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. If you by accident end up in a [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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggest "resolutions that indicate" (instead of "indicates").
Also, consider changing "If you by accident" to "If you accidentally".
| Once the work on an issue has been completed the issue's [Status]{.jbs-field} should be in a "completed" state. There are two "completed" states: [Resolved]{.jbs-value} and [Closed]{.jbs-value}. These are accompanied by a [Resolution]{.jbs-field} and a [Fix Version/s]{.jbs-value}. Which combination of [Status]{.jbs-field}, [Resolution]{.jbs-field}, and [Fix Version/s]{.jbs-value} you should use depends on how the issue is completed. | ||
|
|
||
| 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. | ||
| 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. If you by accident end up in a [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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be clearer if the instructions suggest moving the issue to the Closed state? Unless resolving the issue involved integrating a changeset into a Project repository.
Perhaps, the instructions should start with the case where the issue needs to go through Resolved, that is when a changeset is integrated, and that happens automatically.
If one has to resolve an issue manually, it should rather go to the Closed state directly, which applies to any resolution other than integrating a changeset. In this case, instead of saying, “Most resolutions are used to close…” (which I found confusing), you could state, “All other resolutions should go directly to the Closed state directly.” Or something similar.
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