Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move to a subtree of rust-lang/rust? #817

Closed
anp opened this issue May 21, 2020 · 6 comments
Closed

Move to a subtree of rust-lang/rust? #817

anp opened this issue May 21, 2020 · 6 comments

Comments

@anp
Copy link
Member

anp commented May 21, 2020

Hi! I'm working on putting together a stabilization PR that will need to update the reference (started in #742) at the same time. I see that git subtrees are now being used to allow clippy to be changed atomically with the main repository. Is there a reason we couldn't do the same with the reference's repository, so that all of the stabilization material could be reviewed atomically?

cc @nikomatsakis

@steveklabnik
Copy link
Member

I am not sure, but I'm not inherently opposed. We don't require that the reference has stuff merged in order to stabilize features anymore, though.

@Mark-Simulacrum
Copy link
Member

We've not yet finished the experimentation phase of the subtree move in the compiler team, so we're not quite ready to extend further. I am uncertain, but currently leaning towards, moving all submodules to subtrees that are Rust-related (we probably don't want to do it for LLVM, for example).

@ehuss
Copy link
Contributor

ehuss commented May 21, 2020

I would prefer not to. I think it is good to have separate reviewers for the documentation, so that it maintains a certain style and consistency. I'm also not sure, how would having it be "atomic" bring much value? If it lags by a few days or weeks, it doesn't seem like it would matter much? Almost nobody writes documentation anyways, do you think this would encourage a significant increase? Also, it sounds like it would be more work for me, which I would prefer to avoid.

@nikomatsakis
Copy link
Contributor

I think we should probably get better about writing documentation, though I'm not sure the best way to do that. I feel like it is fine to have a separate PR and to require a link to it during the stabilization (or at least a filed issue). But this comes back to the conversation about "how best to maintain the reference" more than anything.

All of this is to say that I agree with @ehuss that atomicity isn't that important, but I also agree with @Mark-Simulacrum that we should probably settle on one mechanism. =)

@anp
Copy link
Member Author

anp commented May 21, 2020

OK, a lot more nuance here than I was expecting!

In terms of encouraging better docs behavior -- I wasn't thinking in these terms originally but my general experience is that high friction in contribution experience correlates pretty well with under-served areas of open projects (chicken and egg, perhaps?). As a heuristic, this would suggest that reducing barriers to contributing to the reference would be healthy for it but I don't have a clear sense of the other elements of that tradeoff.

Speaking from my own experience as a sometimes-contributor to Rust I have spent a fair amount of effort navigating the submodule approach which has definitely delayed landing #[track_caller] as I only have so much energy/time/etc to push on it. Worth noting however that this feature is more "docs visible" than most PRs AFAICT.

I filed this in part thinking that I could push on the migration to make my life a bit easier for stabilization if it was a desirable move, but there's clearly more discussion that needs to happen so I'll move forward with the stabilization as two PRs.

@Havvy
Copy link
Contributor

Havvy commented Dec 27, 2020

I don't think anybody else wants to do this right now? Plus, I don't think the reference is actually the correct place to discuss this. This feels more like the domain of infra or maybe the core team and whatever the equivalent of an MCP is? In any case, I'm going to close this and it can be re-opened later if need be.

--

As for the actual opinions on the matter, I have none.

Even if we moved the reference in-tree, I'd still want reference changes to be separate PRs than the changes to the rest of the code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants