Lines Matching full:pull
1 # Pull requests
14 * [Step 8: Opening the pull request](#step-8-opening-the-pull-request)
18 * [Reviewing pull requests](#reviewing-pull-requests)
22 * [Abandoned or stalled pull requests](#abandoned-or-stalled-pull-requests)
29 * [Getting approvals for your pull request](#getting-approvals-for-your-pull-request)
31 * [Waiting until the pull request gets landed](#waiting-until-the-pull-request-gets-landed)
111 The vast majority of pull requests opened against the `nodejs/node`
148 commits any single pull request may have, and many contributors find it easier
186 * `Refs: https://github.com/nodejs/node/pull/3615`
208 contributor landing the pull request will ensure that everything follows
237 Before submitting your changes in a pull request, always run the full Node.js
255 begin the process of opening a pull request by pushing your working branch to
262 ### Step 8: Opening the pull request
264 From within GitHub, opening a new pull request will present you with a
265 [pull request template][]. Please try to do your best at filling out the
268 Once opened, pull requests are usually reviewed within a few days.
272 You will probably get feedback or requests for changes to your pull request.
274 contributors may sign off on the pull request right away, others may have
278 To make changes to an existing pull request, make the changes to your local
280 GitHub will automatically update the pull request.
288 It is also frequently necessary to synchronize your pull request with other
299 risks. If in doubt, you can always ask for guidance in the pull request.
313 Feel free to post a comment in the pull request to ping reviewers if you are
320 All pull requests require "sign off" in order to land. Whenever a contributor
321 reviews a pull request they may find specific details that they would like to
338 In order to land, a pull request needs to be reviewed and [approved][] by
340 pull request has been open for more than 7 days) and pass a
342 objections from other contributors, the pull request can be merged. If you find
343 your pull request waiting longer than you expect, see the
344 [notes about the waiting time](#waiting-until-the-pull-request-gets-landed).
346 When a collaborator lands your pull request, they will post
347 a comment to the pull request page mentioning the commit(s) it
348 landed as. GitHub often shows the pull request as `Closed` at this
350 pull request against (probably `master`), you should see a commit with
353 ## Reviewing pull requests
355 All Node.js contributors who choose to review and provide feedback on Pull
359 expect to be able to block a pull request from advancing simply because you say
361 to working with the contributor to make the pull request better.
366 When reviewing a pull request, the primary goals are for the codebase to improve
367 and for the person submitting the request to succeed. Even if a pull request
369 their effort was not wasted or unappreciated. Every pull request from a new
394 avoid stalling the pull request. Most nits can typically be fixed by the
395 Node.js collaborator landing the pull request but they can also be an
408 have a significant impact on the success of the pull request. Yes, we may land
419 For non-trivial changes, pull requests must be left open for at least 48 hours.
426 ### Abandoned or stalled pull requests
428 If a pull request appears to be abandoned or stalled, it is polite to first
440 work. Collaborators are not permitted to approve their own pull requests.
443 a pull request either by using GitHub's Approval Workflow, which is preferred,
461 Use `Changes requested` to block a pull request from landing. When doing so,
462 explain why you believe the pull request should not land along with an
487 accepted. Claims that a particular pull request will make things faster will
495 If a particular pull request introduces a performance or functional
496 regression, rather than simply rejecting the pull request, take the time to
498 advice on what would make the pull request acceptable, and do not assume that
504 All pull requests that contain changes to code must be run through
517 whether the failure was caused by the changes in the pull request.
523 In most cases, do not squash commits that you add to your pull request during
524 the review process. When the commits in your pull request land, they may be
526 commit message (including links to the pull request, links to relevant issues,
527 and the names of the reviewers). The commit history of your pull request,
528 however, will stay intact on the pull request page.
536 ### Getting approvals for your pull request
538 A pull request is approved either by saying LGTM, which stands for
540 GitHub's pull request review feature can be used during the process.
543 or [the official documentation](https://help.github.com/articles/reviewing-changes-in-pull-requests…
551 Every pull request needs to be tested
556 for you as approvals for the pull request come in.
559 ### Waiting until the pull request gets landed
561 A pull request needs to stay open for at least 48 hours from when it is
564 collaborators may decide it doesn't need to wait. A pull request may well take
582 More than one subsystem may be valid for any particular issue or pull request.
588 [approved]: #getting-approvals-for-your-pull-request
594 [pull request template]: https://raw.githubusercontent.com/nodejs/node/HEAD/.github/PULL_REQUEST_TE…