nordic-dev.net/nixpkgs
nordic-dev.net/nixpkgs
2
0
Fork 0
mirror of https://github.com/NixOS/nixpkgs.git synced 2024-11-22 06:53:01 +00:00
Code Issues Packages Projects Releases Wiki Activity

CONTRIBUTING: Remove now-unneeded mass ping section

Browse Source 
This is not a problem anymore with the parent commit
This commit is contained in:
Silvan Mosberger 2024-10-10 00:11:47 +02:00
parent b01ca00aed
commit c2464034c0
1 changed files with 3 additions and 40 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
CONTRIBUTING.md
View File

@ -193,19 +193,12 @@ The last checkbox is about whether it fits the guidelines in this `CONTRIBUTING.
[rebase]: #rebasing-between-branches-ie-from-master-to-staging [rebase]: #rebasing-between-branches-ie-from-master-to-staging
From time to time, changes between branches must be rebased, for example, if the From time to time, changes between branches must be rebased, for example, if the
number of new rebuilds they would cause is too large for the target branch. When number of new rebuilds they would cause is too large for the target branch.
rebasing, care must be taken to include only the intended changes, otherwise
many CODEOWNERS will be inadvertently requested for review. To achieve this,
rebasing should not be performed directly on the target branch, but on the merge
base between the current and target branch. As an additional precautionary measure,
you should temporarily mark the PR as draft for the duration of the operation.
This reduces the probability of mass-pinging people. (OfBorg might still
request a couple of persons for reviews though.)
In the following example, we assume that the current branch, called `feature`, In the following example, we assume that the current branch, called `feature`,
is based on `master`, and we rebase it onto the merge base between is based on `master`, and we rebase it onto the merge base between
`master` and `staging` so that the PR can eventually be retargeted to `master` and `staging` so that the PR can be retargeted to
`staging` without causing a mess. The example uses `upstream` as the remote for `NixOS/nixpkgs.git` `staging`. The example uses `upstream` as the remote for `NixOS/nixpkgs.git`
while `origin` is the remote you are pushing to. while `origin` is the remote you are pushing to.
@ -234,36 +227,6 @@ git status
git push origin feature --force-with-lease git push origin feature --force-with-lease
``` ```
#### Something went wrong and a lot of people were pinged
It happens. Remember to be kind, especially to new contributors.
There is no way back, so the pull request should be closed and locked
(if possible). The changes should be re-submitted in a new PR, in which the people
originally involved in the conversation need to manually be pinged again.
No further discussion should happen on the original PR, as a lot of people
are now subscribed to it.
The following message (or a version thereof) might be left when closing to
describe the situation, since closing and locking without any explanation
is kind of rude:
```markdown
It looks like you accidentally mass-pinged a bunch of people, which are now subscribed
and getting notifications for everything in this pull request. Unfortunately, they
cannot be automatically unsubscribed from the issue (removing review request does not
unsubscribe), therefore development cannot continue in this pull request anymore.
Please open a new pull request with your changes, link back to this one and ping the
people actually involved in here over there.
In order to avoid this in the future, there are instructions for how to properly
rebase between branches in our [contribution guidelines](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#rebasing-between-branches-ie-from-master-to-staging).
Setting your pull request to draft prior to rebasing is strongly recommended.
In draft status, you can preview the list of people that are about to be requested
for review, which allows you to sidestep this issue.
This is not a bulletproof method though, as OfBorg still does review requests even on draft PRs.
```
## How to backport pull requests ## How to backport pull requests
[pr-backport]: #how-to-backport-pull-requests [pr-backport]: #how-to-backport-pull-requests