Skip to content

Commit 3b50943

Browse files
aDotInTheVoidteor2345
authored andcommitted
rustdoc-types-maintainers: More typo fixes
Co-authored-by: teor <[email protected]>
1 parent 4212704 commit 3b50943

File tree

1 file changed

+8
-10
lines changed

1 file changed

+8
-10
lines changed

text/0000-rustdoc-types-maintainers.md

Lines changed: 8 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -39,7 +39,7 @@ Additionally, if an update to `rustdoc-json-types` happens while i'm away from a
3939
This involves:
4040

4141
1. Moving the [github.com/aDotInTheVoid/rustdoc-types](https://github.com/aDotInTheVoid/rustdoc-types/) repo to the `rust-lang` organization, and make `rust-lang/rustdoc` maintainers/owners.
42-
2. Move overship of `rustdoc-types` on crates.io to the rustdoc team.
42+
2. Move ownership of `rustdoc-types` on crates.io to the rustdoc team.
4343

4444
# Reference-level explanation
4545
[reference-level-explanation]: #reference-level-explanation
@@ -48,21 +48,19 @@ This involves:
4848

4949
Republishing `rustdoc-json-types` as `rustdoc-types` is done with [a script](https://github.com/aDotInTheVoid/rustdoc-types/blob/577a774c2433beda669271102a201910c4169c0c/update.sh) so that it is as low maintenance as possible. This also ensures that all format/documentation changes happen in the rust-lang/rust repo, and go through the normal review process there.
5050

51-
`rustdoc-types` is a republishing of the in-tree [`rustdoc-json-types`](https://github.com/rust-lang/rust/tree/b8536c1aa1973dd2438841815b1eeec129480e45/src/rustdoc-json-types) crate. `rustdoc-json-types` is a dependency of `librustdoc`, and is the canonical source of truth for the canonical description of the rustdoc-json output format. Changes to the format are made a a PR to `rust-lang/rust`, and will modify `src/rustdoc-json-types`, `src/librustdoc/json` and `tests/rustdoc-json`. None of this will change.
52-
5351
The update/publishing process will be moved to T-Rustdoc. In the medium term, I (`@aDotInTheVoid`) will still do it, but
54-
- In an offical capacity
52+
- In an official capacity
5553
- With bus factor for when I stop.
5654

5755
## Actual Mechanics of the move
5856

5957
### Github
6058

61-
Github has a [list of requirements](https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository) for transfering repositories.
59+
Github has a [list of requirements](https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository) for transferring repositories.
6260

6361

6462
- When you transfer a repository that you own to another personal account, the new owner will receive a confirmation email. The confirmation email includes instructions for accepting the transfer. If the new owner doesn't accept the transfer within one day, the invitation will expire.
65-
- N/A: Not transfering to
63+
- N/A: Not transferring to another personal account
6664
- To transfer a repository that you own to an organization, you must have permission to create a repository in the target organization.
6765
- I (`@aDotInTheVoid`) don't have create-repo perms in the `rust-lang` org. Therefore I'll add a member of T-Infra as an owner to `aDotInTheVoid/rustdoc-types` (I can't add teams, as it's not in an org). They'll then move it to the repo to the `rust-lang` org. Once moved, T-Infra can become owners.
6866
- The target account must not have a repository with the same name, or a fork in the same network.
@@ -98,12 +96,12 @@ The `rust-lang-owner` is needed because team owners cannot add new owners.
9896
# Rationale and alternatives
9997
[rationale-and-alternatives]: #rationale-and-alternatives
10098

101-
- We could keep `rustdoc-types` as a personal project. This preserves the status quo (and is what will happen if this RFC (or something similar) isn't addopted). This is undesirable because
102-
- Bus factor: If I am unable or unwilling to maintain `rustdoc-types`, we cause a load of unnessessary churn when it becomes out of sync with
99+
- We could keep `rustdoc-types` as a personal project. This preserves the status quo (and is what will happen if this RFC (or something similar) isn't adopted). This is undesirable because
100+
- Bus factor: If I am unable or unwilling to maintain `rustdoc-types`, we cause a load of unnecessary churn when it becomes out of sync with the in-tree `rustdoc-json-types`
103101
- We could bundle `rustdoc-types` through rustup. This is undesirable as it means users can't depend on it in stable rust, and can't depend on multiple versions.
104102
- We could publish `rustdoc-json-types` directly from `rust-lang/rust`. However
105103
- `rust-lang/rust` doesn't currently publish to crates.io.
106-
- `rustdoc-json-types` doesn't currently bump the version field in cargo.toml
104+
- `rustdoc-json-types` doesn't currently bump the version field in `Cargo.toml`
107105
- It may be desirable to use different types in rustdoc vs users, eg to have a specialized version of `Id` that doesn't allocate
108106
- `rustdoc-types` is a nicer name, and what people already depend on.
109107

@@ -112,7 +110,7 @@ The `rust-lang-owner` is needed because team owners cannot add new owners.
112110
[prior-art]: #prior-art
113111

114112
- [Rust RFC 3119](https://rust-lang.github.io/rfcs/3119-rust-crate-ownership.html) establishes the Rust crate ownership policy. Under it's categories, `rustdoc-types` would be a **Intentional artifact**
115-
- [Some old zulip discussion about why `rustdoc-json-types` was created.](https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/JSON.20Format/near/223685843) What was said then is that if T-Rustdoc want's to publish a crate, it needs to go through an RFC. This is that RFC.
113+
- [Some old zulip discussion about why `rustdoc-json-types` was created.](https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/JSON.20Format/near/223685843) What was said then is that if T-Rustdoc wants to publish a crate, it needs to go through an RFC. This is that RFC.
116114

117115
# Unresolved questions
118116
[unresolved-questions]: #unresolved-questions

0 commit comments

Comments
 (0)