Please, before merging pull requests, let’s try to follow some steps:
Assign a milestone for the pull request.
If the change is relevant to be added to the release changelog, please add the labelchangelog.
If the pull request is a fix or small improvement set the labelbackport-4.2.x (I’ll manage periodically about this).
If the pull request is intended to be backported, please use the option Squash and merge, otherwise if the pull request has several commits, it becomes difficult to back port.
Sure I can add that, but also these properties can’t usually be set by contributors, unless they are also committers. It’s something we should set when reviewing pull requests.
Please, before merging pull requests, let’s try to follow some steps:
Assign a milestone for the pull request.
If the change is relevant to be added to the release changelog, please add the labelchangelog.
If the pull request is a fix or small improvement set the labelbackport-4.2.x (I’ll manage periodically about this).
If the pull request is intended to be backported, please use the option Squash and merge, otherwise if the pull request has several commits, it becomes difficult to back port.
I disabled merge commits for pull requests. I was not aware that it could be disabled.
About the backports, Jody indicated they use in GeoServer a GitHub action to create an automatic backport PR. But in any case will require to assign the propert labels.
I know that I missed several times the necessity to do “squash and merge”, sorry for that. But wouldn’t it be simpler to just enforce it in the repository settings? This is an irreversible action and it is error-prone in my view (especially since the requested choice is not the default one).
Sure I can add that, but also these properties can’t usually be set by contributors, unless they are also committers. It’s something we should set when reviewing pull requests.
Please, before merging pull requests, let’s try to follow some steps:
Assign a milestone for the pull request.
If the change is relevant to be added to the release changelog, please add the labelchangelog.
If the pull request is a fix or small improvement set the labelbackport-4.2.x (I’ll manage periodically about this).
If the pull request is intended to be backported, please use the option Squash and merge, otherwise if the pull request has several commits, it becomes difficult to back port.
talks about creating the next release changelog page, making use of git note to provide an automated way to indicate if a change is to be added to the changelog. These changes are gathered into a markdown file when making a new release.
Background: I feel that indicating if a pull request should be noted in the change log (either by process or by git note … is hard to check). I considered recommending making the “the next” change log in the docs, and then the pull-request adding a change can include a commit updating the change-log (easy to check). But this means that the pull-request cannot be cherry-picked (and thus automatically backported by the backport bot). The use of git note attaches the “change log message” to the commit, so it would show up when generating change log on the older branch.
So use of “git note” automates Jose’s proposed workflow; with less room for manually mistake of missing something.
