mirror of
https://github.com/NixOS/nixpkgs.git
synced 2024-11-25 00:12:56 +00:00
CONTRIBUTING: Remove now-unneeded mass ping section
This is not a problem anymore with the parent commit
(cherry picked from commit c2464034c0
)
This commit is contained in:
parent
b2bfec90cd
commit
3493325e09
@ -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
|
||||
|
||||
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
|
||||
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.)
|
||||
number of new rebuilds they would cause is too large for the target branch.
|
||||
|
||||
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
|
||||
`master` and `staging` so that the PR can eventually be retargeted to
|
||||
`staging` without causing a mess. The example uses `upstream` as the remote for `NixOS/nixpkgs.git`
|
||||
`master` and `staging` so that the PR can be retargeted to
|
||||
`staging`. The example uses `upstream` as the remote for `NixOS/nixpkgs.git`
|
||||
while `origin` is the remote you are pushing to.
|
||||
|
||||
|
||||
@ -234,36 +227,6 @@ git status
|
||||
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
|
||||
[pr-backport]: #how-to-backport-pull-requests
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user