Skip to content

Commit

Permalink
Merge pull request #44 from rustcoreutils/docs
Browse files Browse the repository at this point in the history
update CONTRIBUTING
  • Loading branch information
jgarzik authored Apr 15, 2024
2 parents 192a495 + a92be35 commit 2c9ff22
Showing 1 changed file with 15 additions and 8 deletions.
23 changes: 15 additions & 8 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,8 @@ There are several ways to contribute to posixutils-rs:
3. Test coverage: Integration tests, positive and negative, are complete, pass 100%
4. Code coverage: Automated code coverage data indicates 100%
5. Translated: All strings are internationalized, including common OS errors for common error cases.
6. Audited: An external party has reviewed and tested for POSIX compliance.
6. Audited: An external party has reviewed and tested for correctness,
POSIX compliance, security, races and similar issues.

### Coding considerations

Expand All @@ -31,18 +32,24 @@ There are several ways to contribute to posixutils-rs:
2. Ideal goal: **Each utility should look like a standard Rust CLI program.**
Small, lightweight utility with command line processing,
core algorithm, and zero external crate dependencies.
3. "only std" When an external crate is required, avoid mega-crates. Prefer std-only, or, tiny
crates such as `atty` that perform a single, lightweight function.
3. "only std" When an external crate is required, avoid mega-crates. Prefer
std-only, or, tiny crates such as `atty` that perform a single,
lightweight function.
4. Correctness, readability, performance, in that order.
Code should be readable by unfamiliar developers.
Avoid dense, uncommented code.
Code should be readable by unfamiliar developers. Avoid dense,
uncommented code.

### Testing and POSIX compliance goals
### Testing, POSIX compliance and programmaticgoals

* All utilities should have tests.
* Only "quick" tests should be run automatically in `cargo test`
* Goal #1: POSIX compliance
* Goal #2: Support the most popular Linux/BSD extesnsions
* Longer tests, or tests requiring root access, should be triggered
via special environment variables.
* POSIX compliance
* Support the most widely used GNU/BSD extensions
* If a system has an OS-specific feature that _must_ be
exposed through a given utility, do so.
* Race-free userland. `walker` crate should be able to help.

### Testing and Bug Reporting

Expand Down

0 comments on commit 2c9ff22

Please sign in to comment.