TL;DR: Circular dependencies between the respective testing of separate git repositories are bad when landing is gated on tests.
I’m making a breaking change to an
#[unstable] API in https://github.com/rust-lang/rust/pull/46952. No problem, I’ll update its usage in the repository at the same time so that
./x.py test passes. Some of these changes turn out to be in doctests under
src/doc/nomicon which is a submodule. No problem I’ll submit a PR to that repository first. But that PR can’t land because that repository has its own CI that runs the same doctests with Rust Nigthly. So I’d need to get my changes in Rust Nightly to be able to land my nomicon PR. But to do that I first need to land my nomicon PR.
I seem to be stuck.
But there’s a trick: for changing which commit hash the
src/doc/nomicon submodule points to I don’t need that commit to be in the
master branch, I just need it to be reachable somehow when one clones the repository. So I can ask someone with write access to
rust-lang-nursery/nomicon to create a new branch there, then create another PR that goes into that branch instead of master. I ask for that PR to be merged without testing (which is not too bad because it’s not master) and now I can push a submodule update to my
rust-lang/rust PR that Travis-CI won’t fail to fetch. When the original PR will land and reach Nightly, I’ll then be able to land the nomicon PR into nomicon master.
Some time passes while my original PR is discussed and review. In the meantime, some other change lands into nomicon and the submodule is updated on
rust-lang/rust master. Now my original PR has a merge conflict. To solve that I need to do the whole temporary branch dance all over again.
All in all, this kind of change require jumping through many more hoops than I feel should be necessary.
I think this can be fixed in two ways. For nomicon and other submodules whose content rely on unstable features:
- Stop running tests for them in
./x.py test. They would become like third-party projects that use unstable features: they might break in a new Nightly, and it’s up to them to update at their own pace.
- Or, stop gating PRs to these repository on passing tests with Nightly. Move to testing them exclusively when updating what commit a submodule points to. At this point it becomes debatable why they’re in a separate repository at all rather than directly in
(Some submodules like Cargo for example don’t have this problem because they only use stable features.)