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
contributing.md: change labels on backported PRs #109263
contributing.md: change labels on backported PRs #109263
Conversation
.github/CONTRIBUTING.md
Outdated
@@ -57,6 +57,7 @@ Follow these steps to backport a change into a release branch in compliance with | |||
3. Create a branch for your change, e.g. `git checkout -b backport`. | |||
4. When the reason to backport is not obvious from the original commit message, use `git cherry-pick -xe <original commit>` and add a reason. Otherwise use `git cherry-pick -x <original commit>`. That's fine for minor version updates that only include security and bug fixes, commits that fixes an otherwise broken package or similar. Please also ensure the commits exists on the master branch; in the case of squashed or rebased merges, the commit hash will change and the new commits can be found in the merge message at the bottom of the master pull request. | |||
5. Push to GitHub and open a backport pull request. Make sure to select the release branch (e.g. `release-20.09`) as the target branch of the pull request, and link to the pull request in which the original change was comitted to `master`. The pull request title should be the commit title with the release version as prefix, e.g. `[20.09]`. | |||
6. When the backport pull request is merged, reference the cherry-picked commit in the original pull request. If you have the privileges you can also remove the label `9.needs: port to stable` and replace it with `8.has: port to stable`. This way maintainers can keep track of missing backports easier. |
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.
When the backport pull request is merged, reference the cherry-picked commit in the original pull request.
I wouldn't want to put that extra work on someone. Just put the #XXX of the original PR in the backported PR.
If you have the privileges you can also remove the label
9.needs: port to stable
and replace it with8.has: port to stable
. This way maintainers can keep track of missing backports easier.
Ideally this would be done by a bot because this is easily automatable.
Also
If you have the permissions you can alsoreplace the label
9.needs: port to stable
with8.has: port to stable
. This way maintainers can keep track of missing backports easier.
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.
I wouldn't want to put that extra work on someone. Just put the #XXX of the original PR in the backported PR.
Agreed.
Ideally this would be done by a bot because this is easily automatable.
I'm not so sure about this. Matching PRs with their backports doesn't seem trivial to me. E.g. people tend to not write the exact [20.09]
in the PR title and sometimes backport PRs address multiple PRs to unstable. Could we keep this part until a bot is written, that solves this problem?
This is somewhat convention already and it makes keeping track of missing backports a lot easier.
f099e46
to
073ddd8
Compare
This is somewhat convention already and it makes keeping track of
missing backports a lot easier.
Motivation for this change
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)