Lines Matching refs:a
13 It should be considered a map to help you navigate the process.
18 Tonic is a part of the [Tokio][tokio] and [Hyperium][hyperium] project, and follows the project's
39 have uncovered a bug in a `tonic` crate, creating a new issue in the
43 supporting details (a test case that demonstrates a bug), providing
48 demonstrating that the issue reported is not a problem after all, or more
49 often, by opening a Pull Request that changes some bit of something in
50 Tokio in a concrete and reviewable manner.
62 In exchange for receiving help, we ask that you contribute back a documentation
65 ### Submitting a Bug Report
67 When opening a new issue in the `tonic` issue tracker, users will
68 be presented with a [basic template][template] that should be filled in. If you
69 believe that you have uncovered a bug, please fill out this form, following the
74 evaluate the report is a description of the behavior you are seeing and a simple
81 See [How to create a Minimal, Complete, and Verifiable example][mcve].
86 ### Triaging a Bug Report
90 including whether the behavior being seen is a bug or a feature. This discussion
99 to comment on an issue that you feel either is not a problem that needs to be
105 ### Resolving a Bug Report
107 In the majority of cases, issues are resolved by opening a Pull Request. The
108 process for opening and reviewing a Pull Request is similar to that of opening
109 and triaging issues, but carries with it a necessary review and approval
118 Even tiny pull requests (e.g., one character pull request fixing a typo in API
119 documentation) are greatly appreciated. Before making a large change, it is
120 usually a good idea to first open an issue describing the change to solicit
127 example), it is either adding new functionality to a crate or it is fixing
136 crate should have a `dev-dependency` on `tonic` itself. This makes all
140 The best strategy for writing a new integration test is to look at existing
149 The trick to documentation tests is striking a balance between being succinct
150 for a reader to understand and actually testing the API.
152 The type level example for `tokio_timer::Timeout` provides a good example of a
175 /// // Wrap the future with a `Timeout` set to expire in 10 milliseconds.
181 Given that this is a *type* level documentation test and the primary way users
187 easiest way to execute a future from a test.
189 If this were a documentation test for the `Timeout::new` function, then the
203 /// // Wrap the future with a `Timeout` set to expire in 10 milliseconds.
222 It is a recommended best practice to keep your changes as logically grouped as
227 That said, if you have a number of commits that are "checkpoints" and don't
228 represent a single logical change, please squash those together.
239 * contain a short description of the change (preferably 50 characters or less,
253 4. If your patch fixes an open issue, you can add a reference to it at the end
255 references use `Refs: #`. `Refs` may include multiple issues, separated by a
268 Body of commit message is a few lines of text, explaining things
283 From within GitHub, opening a new Pull Request will present you with a
292 This is a big part of the submission process so don't be discouraged! Some
294 more detailed comments or feedback. This is a necessary part of the process
297 **Any community member can review a PR and you might get conflicting feedback**.
318 Requests have a responsibility to both the project and the individual making the
322 expect to be able to block a Pull Request from advancing simply because you say
329 When reviewing a Pull Request, the primary goals are for the codebase to improve
330 and for the person submitting the request to succeed. **Even if a Pull Request
332 their effort was not wasted or unappreciated**. Every Pull Request from a new
335 ### Review a bit at a time.
347 4. Is the commit message readable and correct? If it contains a breaking change
350 Note that only **incremental** improvement is needed to land a PR. This means
355 assume that the submitter already knows how to add a test or run a benchmark**.
358 change over time. The first impression you give to a new contributor never does.
363 the contributor to learn a bit more about the project.
369 commits or if they proved to be mistaken, please, [hide them][hiding-a-comment]
375 have a significant impact on the success of the Pull Request. Yes, we may land
376 a particular change that makes `tonic` better, but the individual might
382 If a Pull Request appears to be abandoned or stalled, it is polite to first
392 [hiding-a-comment]: https://help.github.com/articles/managing-disruptive-comments/#hiding-a-comment
397 Since the Tonic project consists of a number of crates, many of which depend on
399 When releasing a new version of a crate, follow these steps:
402 changes make sure to select a semver compatible version bump.
406 the core version of tonic. To prepare a release branch you can follow the
425 4. Once the changelog has been updated you can now create a `chore: release
426 vX.Y.Z` commit and push the release branch and open a release PR.
435 6. Once all the crates have been released you now must create a release on