-
Notifications
You must be signed in to change notification settings - Fork 498
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
Comments
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. |
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). |
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. |
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. =) |
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 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. |
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. |
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
The text was updated successfully, but these errors were encountered: