RFR: Section on project maintenance [v3]

Jesper Wilhelmsson jwilhelm at openjdk.org
Tue Dec 20 12:53:47 UTC 2022


On Thu, 22 Sep 2022 08:30:32 GMT, David Simms <dsimms at openjdk.org> wrote:

>> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update after Ludvig's review
>
> src/guide/project-maintenance.md line 38:
> 
>> 36: 
>> 37: We start by updating the local fork with the latest changes from the main project repository. Note that we then create a new branch in which the merge will happen.
>> 38: 
> 
> Merging from what ever is latest is not usually a good idea, mainline code is not "clean" for any given commit. Merging JDK tags ensures you have a known quantity, those tagged commits are known to compile and test. 
> 
> Check which tags have not been merged: `git tag -l "$PREFIX*" --no-merged` (e.g. `PREFIX="jdk-24"`) and merge up to said tag: `git merge $TAG`
> 
> Before merging, you may want to check what is incoming, and get an idea of the size of the merge and look for any incoming changes that you suspect may cause issues (`git log --topo-order --pretty=oneline --reverse ..$CHANGE`).

Good suggestions. Added.

> src/guide/project-maintenance.md line 52:
> 
>> 50: Make sure the name of the PR starts with "Merge". You may have noticed that when you integrate a "normal" PR into an OpenJDK repository, all commits that have been done in that PR will be squashed into a single commit. For normal changes this is a good thing as each PR normally corresponds to a single JBS issue, but for a merge it would be highly undesirable to squash all the different commits that you pull in from mainline. A PR with a name that starts with "Merge" won't be squashed. That means that all the changes that you brought over will remain separate changes.
>> 51: 
>> 52: Wether a merge requires a review or not is up to your project lead to decide. Many projects don't require this so the GitHub bots will allow you to push the merge as soon as the [GHA](#github-actions)s are done. (They actually allow you to push even before the GHAs are done, but that's in general not a good idea.)
> 
> Wether => Whether

Fixed.

> src/guide/project-maintenance.md line 53:
> 
>> 51: 
>> 52: Wether a merge requires a review or not is up to your project lead to decide. Many projects don't require this so the GitHub bots will allow you to push the merge as soon as the [GHA](#github-actions)s are done. (They actually allow you to push even before the GHAs are done, but that's in general not a good idea.)
>> 53: 
> 
> What was merged ? Recommend adding summary, e.g: `/summary Merge tag 'jdk-22+9'"`

Added this.

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

PR: https://git.openjdk.org/guide/pull/92


More information about the guide-dev mailing list