dist(release/1.29): backport patches, pt. 1#4867
Conversation
PartialTargetTriple::is_empty()
rami3l
added
the
backport
This alias was originally added in 7e1eeb9. This applies that same alias to all places where -y is used to suppress a confirmation prompt. Specifically, that includes rustup-init, the downloader script and `rustup self uninstall`.
|
Well, there ARE some rough edges but should be pretty simple to resolve, I'll find some time to look at them later... At least there has been 0 conflicts during the rebase which is quite impressive in itself already :o |
rami3l
changed the title
Co-authored-by: Francisco Gouveia <francisco.t.gouveia@tecnico.ulisboa.pt>
…istributableToolchain::install()`
Co-authored-by: rami3l <rami3l@outlook.com>
Co-authored-by: rami3l <rami3l@outlook.com>
…ode on Unix Co-authored-by: rami3l <rami3l@outlook.com>
Co-authored-by: rami3l <rami3l@outlook.com>
|
So far I think the backporting overhead is surprisingly low. Next up I guess it's okay to merge this first, and then I'll add a deprecation warning for #4840 in the backport. |
|
Probably should wire up the release branch to get merge queue support, as well? I forget where/how that happens. |
@djc That's in the original plan but then the team has found out that it's technically impossible (GitHub restrictions, see rust-lang/team#2372 (comment)). However auto-merge is enabled plus the contention is almost inexistent on backport targets so that should work as a second best. |
|
I think it might still be good to have that configuration without wildcards (having to do a PR per minor release branch doesn't seem too bad). |
|
@djc I would argue that the benefits of adding a merge queue is mostly that of auto merge + a bit of contention protection. Actually, I have already added the same required checks as in trunk in addition to auto merge in https://github.com/rust-lang/team/pull/2437/changes, and given that I believe the CI quality itself should be the same. As for the contending PR part, we shouldn't expect a lot of (>3) PRs open against the same backport target, so that part is also fine. |
11 participants
Part of #4862.
Warning
This is an experimentation of how backporting could possibly work. Don't merge yet.
@djc wow, with atomic commits, backporting is as simple as dropping the incompatible commits? I'm impressed...