forked/h2

Files

Oliver Gould 897bf84163 Use rustfmt to enforce consistent formatting

This change adds a .rustfmt.toml that includes ALL supported settings,
12 of which we have overridden to attempt to cater to our own
proclivities.

rustfmt is checked in the rust-nightly CI job.

2017-09-12 22:29:35 +00:00

2.7 KiB

Raw Blame History

Contributing to h2

🎈 Thanks for your help improving the project!

Getting Help

If you have a question about the h2 library or have encountered problems using it, you may file an issue or ask ask a question on the Tokio Gitter.

Submitting a Pull Request

Do you have an improvement?

Submit an issue describing your proposed change.
We will try to respond to your issue promptly.
Fork this repo, develop and test your code changes. See the project's README for further information about working in this repository.
Submit a pull request against this repo's master branch.
Your branch may be merged once all configured checks pass, including:
- Code review has been completed.
- The branch has passed tests in CI.

Code Style

rustfmt-nightly is used to enforce a consistent style (as configured by .rustfmt.toml). Style is checked by CI, so be sure to apply rustfmt before committing your work. For example:

$ rustup run nightly cargo install --force rustfmt-nightly
    Updating registry `https://github.com/rust-lang/crates.io-index`
  Installing rustfmt-nightly v0.2.5
...
$ rustup run nightly cargo fmt

Committing

We prefer squash or rebase commits so that all changes from a branch are committed to master as a single commit. All pull requests are squashed when merged, but rebasing prior to merge gives you better control over the commit message.

Commit messages

Finalized commit messages should be in the following format:

Subject

Problem

Solution

Validation

Subject

one line, <= 50 characters
describe what is done; not the result
use the active voice
capitalize first word and proper nouns
do not end in a period — this is a title/subject
reference the github issue by number

Examples

bad: server disconnects should cause dst client disconnects.
good: Propagate disconnects from source to destination

bad: support tls servers
good: Introduce support for server-side TLS (#347)

Problem

Explain the context and why you're making that change. What is the problem you're trying to solve? In some cases there is not a problem and this can be thought of as being the motivation for your change.

Solution

Describe the modifications you've made.

Validation

Describe the testing you've done to validate your change. Performance-related changes should include before- and after- benchmark results.

2.7 KiB Raw Blame History