Lines Matching refs:land

85 As soon as the pull request is ready to land, please do so. This allows other
87 to land but is [author ready](#author-ready-pull-requests), add the
88 `author ready` label. If you wish to land the pull request yourself, use the
140 A pull request can land if it has the needed [approvals](#code-reviews),
177 Certain types of pull requests can be fast-tracked and can land after a shorter
194 fast-tracking request. To land, the pull request itself still needs two
206 Do not land any pull requests without the necessary passing CI runs.
453 the three Deprecation levels. Documentation-Only Deprecations can land in a
488    who wish to land their own pull requests will self-assign them. Sometimes, an
490    it is okay to land.
518 is enough to land a pull request. If you discover a problem when using
525 $ git node land $PRID
536 Infrequently, it is necessary to manually perform the steps required to land a
753 Commits that land on master are cherry-picked to each staging branch as
755 against the *staging* branch. Commits from the staging branch land on the LTS
756 branch only when a release is being prepared. They might land on the LTS branch
759 Only members of @nodejs/backporters should land commits onto LTS staging
774 * `land-on-` are for pull requests that should land in a future v*.x
775   release. For example, `land-on-v10.x` would be for a change to land in Node.js
779 land on the staging branches, the backporter removes the `lts-watch-` label.
780 Likewise, as commits land in an LTS release, the releaser removes the `land-on-`
871 We use labels to keep track of which branches a commit should land on:
873 * `dont-land-on-v?.x`
876 * `land-on-v?.x`
883     order to land the changes on that branch
886   * Will be replaced by either `dont-land-on-v?.x` or `backported-to-v?.x`