Lines Matching +full:pull +full:- +full:requests
20 [`CONTRIBUTING.md` file][tokio-contrib] in the `tokio-rs/tokio` repository.
22 [dev]: https://gitter.im/tokio-rs/dev
24 [tokio-contrib]: https://github.com/tokio-rs/tokio/blob/master/CONTRIBUTING.md
31 [coc]: https://github.com/rust-lang/rust/blob/master/CODE_OF_CONDUCT.md
39 tokio-rs/tracing [issue tracker][issues] is the way to report it.
48 often, by opening a Pull Request that changes some bit of something in
54 [issues]: https://github.com/tokio-rs/tracing/issues
67 be presented with a [basic template][issue-template] that should be filled in. If you
83 [issue-template]: .github/ISSUE_TEMPLATE/bug_report.md
106 In the majority of cases, issues are resolved by opening a Pull Request. The
107 process for opening and reviewing a Pull Request is similar to that of opening
112 ## Pull Requests
114 Pull Requests are the way concrete changes are made to the code, documentation,
117 Even tiny pull requests (e.g., one character pull request fixing a typo in API
127 existing, broken functionality. In both of these cases, the pull request should
135 crate should have a `dev-dependency` on `tracing` itself. This makes all
145 use the API. Documentation tests are run with `cargo test --doc`. This ensures
208 To reduce the effort required to review documentation-related changes,
212 `netlify/tracing-rs/deploy-preview check` on all pull requests.
216 Tracing's documentation uses nightly-only RustDoc features and lints, like
218 passing `--cfg docsrs` to RustDoc. Therefore, in order to build Tracing's
223 RUSTDOCFLAGS="--cfg docsrs" cargo +nightly doc --no-deps
230 any single Pull Request may have, and many contributors find it easier to review
255 * tower-http: add `Clone` impl for `Service` and `MakeService`
266 - `Fixes: #1337`
267 - `Refs: #1234`
279 please do proper word-wrap and keep columns shorter than about
287 ### Opening the Pull Request
289 From within GitHub, opening a new Pull Request will present you with a
290 [pull-request-template] that should be filled out. Please try to do your best at filling out
293 [pull-request-template]: .github/PULL_REQUEST_TEMPLATE.md
297 You will probably get feedback or requests for changes to your Pull Request.
299 contributors may sign off on the Pull Request right away, others may have
312 In most cases, **do not squash commits that you add to your Pull Request during
313 the review process**. When the commits in your Pull Request land, they may be
315 commit message (including links to the Pull Request, links to relevant issues,
316 and the names of the reviewers). The commit history of your Pull Request,
317 however, will stay intact on the Pull Request page.
319 ## Reviewing Pull Requests
321 **Any Tokio community member is welcome to review any pull request**.
323 All Tokio contributors who choose to review and provide feedback on Pull
324 Requests have a responsibility to both the project and the individual making the
328 expect to be able to block a Pull Request from advancing simply because you say
330 to working with the contributor to make the Pull Request better.
335 When reviewing a Pull Request, the primary goals are for the codebase to improve
336 and for the person submitting the request to succeed. **Even if a Pull Request
338 their effort was not wasted or unappreciated**. Every Pull Request from a new
345 It is tempting to micro-optimize and make everything about relative performance,
366 Nits (requests for small changes that are not essential) are fine, but try to
367 avoid stalling the Pull Request. Most nits can typically be fixed by the Tokio
368 Collaborator landing the Pull Request but they can also be an opportunity for
375 commits or if they proved to be mistaken, please, [hide them][hiding-a-comment]
380 Be aware that *how* you communicate requests and reviews in your feedback can
381 have a significant impact on the success of the Pull Request. Yes, we may land
386 ### Abandoned or Stalled Pull Requests argument
388 If a Pull Request appears to be abandoned or stalled, it is polite to first
393 the commit log, or by using an `Author: ` meta-data tag in the commit.
398 [hiding-a-comment]: https://help.github.com/articles/managing-disruptive-comments/#hiding-a-comment
399 [documentation test]: https://doc.rust-lang.org/rustdoc/documentation-tests.html
412 This should be done through a form of depth-first tree traversal:
427 bin/publish --dry-run <CRATE NAME> <CRATE VERSION>
440 ensure a consistent format, based on [Keep A Changelog][keep-a-changelog].
447 6. **Open a pull request with your changes.** Once that pull request has been
448 approved by a maintainer and the pull request has been merged, continue to
459 [keep-a-changelog]: https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md