- 
                Notifications
    
You must be signed in to change notification settings  - Fork 13.9k
 
meta: notify #t-rustdoc Zulip stream on backport nominations #116957
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
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).triagebotis not quite as flexible has I've hoped. Blocked ontriagebotimprovements (see theFIXMEs in this PR).r? GuillaumeGomez