RFR: Changes due to stabilization branches [v2]

[Jesper Wilhelmsson]

On Tue, 4 Jun 2024 23:52:03 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates after reviews
>
> src/guide/backporting.md line 65:
> 
>> 63: ## How to fix an incorrect backport creation in JBS
>> 64: 
>> 65: If an issue is targeted to a release and a fix referring to that issue is pushed to a different release repository, then a backport issue is automatically created in JBS. Usually this is a "good thing", e.g., when you are backporting a fix to an earlier release, but not always... If the main issue is targeted to a later release (due to schedule planning) but someone finds the time to fix that issue in the current release, or if the main issue is targeted to a feature release in ramp down and the fix is pushed to the mainline master branch, then the issue should be retargeted to the correct release before pushing the fix. However, sometimes we forget.
> 
> "mainline master branch" can probably just be "master branch"

Agreed. Fixed.

> src/guide/cloning-the-jdk.md line 51:
> 
>> 49: 
>> 50: :::{.note}
>> 51: If you intend to work on a backport to a feature release stabilization branch, your new local branch should of course be based on the stabilization branch instead of `master`.
> 
> I would move this note after the below example, and provide a second example that shows basing the branch on the stabilization branch.

Fixed.

> src/guide/working-with-pull-requests.md line 100:
> 
>> 98: 
>> 99:    If there are upstream changes that might affect your change, it's likely a good idea to rerun relevant testing as well. The [GHA testing](#github-actions) that's done automatically by GitHub should only be seen as a smoke test that finds the most severe problems with your change. It's highly unlikely that it will test your actual change in any greater detail - or even at all execute the code that you have changed in most cases.
>> 100:    If your clone was based on some other branch than `master`, make sure to pull from the correct upstream branch. Verify that your PR doesn't include changes from some other branch (e.g. `master`) that aren't supposed to be there.
> 
> Suggested wording: If your PR is targeting some other branch than `master`, make sure to merge the correct upstream branch (the target branch). Verify ...

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/guide/pull/123#discussion_r1626774975
PR Review Comment: https://git.openjdk.org/guide/pull/123#discussion_r1626774933
PR Review Comment: https://git.openjdk.org/guide/pull/123#discussion_r1626775009