-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
meta: notify #t-rustdoc Zulip stream on backport nominations #116957
meta: notify #t-rustdoc Zulip stream on backport nominations #116957
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving the PR just to show my support as I think this is a very nice add! Please ping me once the other blockers have been solved.
Maybe instead of hijacking the
beta-nominated
EDIT: Same for |
Hmm, I'm not super convinced that we need to introduce rustdoc-{beta,stable}-{nominated,accepted} (whatever the naming). I think it would needlessly complicate the backporting process as T-release members would have to remember to not only look for {beta,stable}-accepted but also for rustdoc-{beta,stable}-accepted. It's not the end of the world but I'd say it can be avoided. There are only 7 T-{rustdoc,compiler}beta-accepted PRs out of 77 T-rustdocbeta-accepted PRs which amounts to 9.1%, meaning not that frequent (obviously not accounting for rejected nominations here). We could also update Although the idea of creating I-rustdoc-nominated is pretty good on its own. While we could teach rustdoc reviewers to add I-rustdoc-nominated to {beta,stable}-nominated PRs, personally speaking I much prefer automation if possible. |
I'm not proposing to introduce |
T-release looks for both nominated and accepted labels, any changes here are somewhat painful (especially since backports are currently manual, and expressing the necessary combined query in GitHub would be... difficult). You can read more about the process here - https://forge.rust-lang.org/release/backporting.html So even just the nominated labels changing would be enough to lead to additional pain for the release team. |
This comment was marked as outdated.
This comment was marked as outdated.
12108d2
to
4d1db4d
Compare
This comment was marked as outdated.
This comment was marked as outdated.
4d1db4d
to
75123db
Compare
75123db
to
02ba04a
Compare
02ba04a
to
ec045f6
Compare
I've created a triagebot patch here: rust-lang/triagebot#1791. |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this (again)! 😄
9f2d282
to
1953e9e
Compare
1953e9e
to
8f3d7fe
Compare
PR has been approved. |
…n-backport-nominations, r=GuillaumeGomez meta: notify #t-rustdoc Zulip stream on backport nominations In July '23, it was decided to handle rustdoc-specific backport nominations in t-rustdoc meetings going forward ([Zulip announcement](https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/T-rustdoc.20backports/near/374828518)). However, t-rustdoc meetings are far too infrequent for them to address nominations on time (contrary to the weekly t-compiler meetings). Hence GuillaumeGomez and I came to the conclusion that {beta,stable}-nominated rustdoc PRs should be dealt with on a case by case basis, e.g. on Zulip. This PR attempts to partially automate this process. ~~Sadly, `triagebot` is not quite as flexible has I've hoped. Blocked on `triagebot` improvements (see the `FIXME`s in this PR).~~ (Fixed in rust-lang/triagebot#1791). r? GuillaumeGomez
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#116957 (meta: notify #t-rustdoc Zulip stream on backport nominations) - rust-lang#122201 (Document overrides of `clone_from()` in core/std) - rust-lang#122723 (Use same file permissions for ar_archive_writer as the LLVM archive writer) - rust-lang#124030 (interpret: pass MemoryKind to adjust_alloc_base_pointer) - rust-lang#124037 (Don't ascend into parent bodies when collecting stmts for possible return suggestion) - rust-lang#124049 (Stabilize `const_io_structs`) - rust-lang#124062 (Add another expression to weird-exprs.rs) - rust-lang#124066 (Don't error on subtyping of equal types) - rust-lang#124073 (Remove libc from rust_get_test_int uses) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#116957 - fmease:meta-notify-rustdoc-zulip-on-backport-nominations, r=GuillaumeGomez meta: notify #t-rustdoc Zulip stream on backport nominations In July '23, it was decided to handle rustdoc-specific backport nominations in t-rustdoc meetings going forward ([Zulip announcement](https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/T-rustdoc.20backports/near/374828518)). However, t-rustdoc meetings are far too infrequent for them to address nominations on time (contrary to the weekly t-compiler meetings). Hence GuillaumeGomez and I came to the conclusion that {beta,stable}-nominated rustdoc PRs should be dealt with on a case by case basis, e.g. on Zulip. This PR attempts to partially automate this process. ~~Sadly, `triagebot` is not quite as flexible has I've hoped. Blocked on `triagebot` improvements (see the `FIXME`s in this PR).~~ (Fixed in rust-lang/triagebot#1791). r? GuillaumeGomez
In July '23, it was decided to handle rustdoc-specific backport nominations in t-rustdoc meetings going forward (Zulip announcement). However, t-rustdoc meetings are far too infrequent for them to address nominations on time (contrary to the weekly t-compiler meetings).
Hence GuillaumeGomez and I came to the conclusion that {beta,stable}-nominated rustdoc PRs should be dealt with on a case by case basis, e.g. on Zulip.
This PR attempts to partially automate this process.
Sadly,(Fixed in rust-lang/triagebot#1791).triagebot
is not quite as flexible has I've hoped. Blocked ontriagebot
improvements (see theFIXME
s in this PR).r? GuillaumeGomez