docs: document that we should use libc from git repo when under dev (#2246)

* docs: document that we should use libc from git repo when under dev

* try fix diff

* try fix diff

* respond to review

Author: SteveLauC

CONTRIBUTING.md

@@ -63,7 +63,7 @@ Please make pull requests against the `master` branch.
 If you change the API by way of adding, removing or changing something or if
 you fix a bug, please add an appropriate note, every note should be a new markdown 
 file under the [changelog directory][cl] stating the change made by your pull request, 
-the filename should be in the following foramt:
+the filename should be in the following format:
 
 ```
 <PULL_REQUEST_ID>.<TYPE>.md
@@ -104,17 +104,17 @@ run once you open a pull request.
 
 ### Disabling a test in the CI environment
 
-Sometimes there are features that cannot be tested in the CI environment.  To
+Sometimes there are features that cannot be tested in the CI environment. To
 stop a test from running under CI, add `skip_if_cirrus!()` to it. Please
 describe the reason it shouldn't run under CI, and a link to an issue if
-possible!  Other tests cannot be run under QEMU, which is used for some
-architectures.  To skip them, add a `#[cfg_attr(qemu, ignore)]` attribute to
+possible! Other tests cannot be run under QEMU, which is used for some
+architectures. To skip them, add a `#[cfg_attr(qemu, ignore)]` attribute to
 the test.
 
 ## GitHub Merge Queues
 
 We use GitHub merge queues to ensure that subtle merge conflicts won't result
-in failing code.  If you add or remove a CI job, remember to adjust the
+in failing code. If you add or remove a CI job, remember to adjust the
 required status checks in the repository's branch protection rules!
 
 ## API conventions

CONVENTIONS.md

@@ -17,8 +17,15 @@ We follow the conventions laid out in [Keep A CHANGELOG][kacl].
 
 ## libc constants, functions and structs
 
-We do not define integer constants ourselves, but use or reexport them from the
-[libc crate][libc].
+We do not define ffi functions or their associated constants and types ourselves,
+but use or reexport them from the [libc crate][libc], if your PR uses something 
+that does not exist in the libc crate, you should add it to libc first. Once 
+your libc PR gets merged, you can adjust our `libc` dependency to include that 
+libc change. Use a git dependency if necessary.
+
+```toml
+libc = { git = "https://github.com/rust-lang/libc", rev = "the commit includes your libc PR", ... }
+```
 
 We use the functions exported from [libc][libc] instead of writing our own
 `extern` declarations.
@@ -40,7 +47,7 @@ When creating newtypes, we use Rust's `CamelCase` type naming convention.
 ## cfg gates
 
 When creating operating-system-specific functionality, we gate it by
-`#[cfg(target_os = ...)]`.  If more than one operating system is affected, we
+`#[cfg(target_os = ...)]`. If more than one operating system is affected, we
 prefer to use the cfg aliases defined in build.rs, like `#[cfg(bsd)]`.
 
 ## Bitflags
@@ -115,5 +122,5 @@ To deprecate an interface, put the following attribute on the top of it:
 `<Version>` is the version where this interface will be deprecated, in most 
 cases, it will be the version of the next release. And a user-friendly note 
 should be added. Normally, there should be a new interface that will replace
-the old one, so a note should be something like: "<New Interface> should be 
+the old one, so a note should be something like: "`<New Interface>` should be 
 used instead".

RELEASE_PROCEDURE.md

@@ -4,15 +4,22 @@ library.
 # Before Release
 
 Nix uses [cargo release](https://github.com/crate-ci/cargo-release) to automate
-the release process.  Based on changes since the last release, pick a new
+the release process. Based on changes since the last release, pick a new
 version number following semver conventions. For nix, a change that drops
 support for some Rust versions counts as a breaking change, and requires a
 major bump.
 
 The release is prepared as follows:
 
-- Ask for a new libc version if, necessary. It usually is.  Then update the
-  dependency in Cargo.toml accordingly.
+- Ask for a new libc version if, necessary. It usually is. Then update the
+  dependency in `Cargo.toml` to rely on a release from crates.io.
+ 
+  ```diff
+  [dependencies]
+  -libc = { git = "https://github.com/rust-lang/libc", rev = "<Revision>", features = ["extra_traits"] }
+  +libc = { version = "<New Version>", features = ["extra_traits"] }
+  ```
+  
 - Update the version number in `Cargo.toml`
 - Generate `CHANGELOG.md` for this release by 
   `towncrier build --version=<VERSION> --yes`