Handling release notes for language guarantees made in the Reference

[traviscross]

Recently, in the Reference, we merged rust-lang/reference#2264. This is a new language guarantee, and I'd expect we'd want to document that in the release notes in the same spirit as earlier ones such as:

• Document NaN bit patterns guarantees
• Guarantee layout and ABI of Result in some scenarios
• Document maximum allocation size
• Document Rust ABI compatibility between various types

I'm not certain about the process for this with the new tooling when this guarantee is made in the Reference rather than in rust-lang/rust. I've added a relnotes label in https://github.com/rust-lang/reference to use for this, if that helps.

@rust-lang/release: Thoughts?

cc @ehuss

[Mark-Simulacrum]

I would suggest that whenever the reference is bumped in rust-lang/rust, the PR containing these changes is tagged relnotes and then you can edit the auto-created issue with relevant context. That should ensure it gets picked up by the tooling and milestoned for the right release (once the relnotes PR is merged). Editing the reference by itself doesn't (imo) commit us until that change rides the train to stable after such a submodule bump.

https://forge.rust-lang.org/release/release-notes.html documents the relnotes process in more detail.

[traviscross]

Thanks. I worry, in practice, that we'll miss these without tooling support. We reliably bump the submodule pointer for the books ahead of each beta bump (and, between those, at other intervals). But we don't have a system for working backward from this to find everything that should be in the release notes when doing these mechanical bumps.

https://forge.rust-lang.org/release/release-notes.html documents the relnotes process in more detail.

In that document, it notes:

Once labeled, a new issue is automatically filed with title “Tracking issue for release notes of #xxxx: $original pr title”...

Note that this step happens on labeling, not necessarily when the issue/PR is merged/closed.

In the Reference, I'd expect us to add these labels when merging. Then, since we reliably update the submodule pointer ahead of the beta bump, it should be roughly predictable in which release the item will land.

Would it make any sense to extend this create-relnotes-tracking-issue-on-labeling behavior to the Reference repo as well? (I imagine these tracking issues would live in rust-lang/rust.)

[Mark-Simulacrum]

Hm, I see. I missed that a good portion of this is already automated (in particular file the book update PR), which I think makes it simpler to get this right.

Someone would need to:

1. Adjust the relnotes handler to cut rust-lang/rust tracking issues when the reference PR is tagged "relnotes" (or FCP).
2. Adjust the milestone PRs handler to also milestone reference PRs. We seem to already do this for Cargo -- I'm not sure how reliable it is, the GitHub search seems broken for no:milestone PRs, but assuming that works it's a few lines of change to get that working.
3. Adjust the relnotes handler to set the milestone on the rust-lang/rust tracking issue when the reference PR is milestoned. That might happen without any changes -- not entirely sure based on the code.
4. Update the relnotes tool to properly handle tracking issues where the PR is on a different repository. I'm not sure how easy that will be, maybe it's a case of extending https://github.com/rust-lang/relnotes/blob/0892147a9519a56cc156924e8f33451656dc4f1b/src/main.rs#L98? But it may prove harder. The issue <> PR mapping is pretty hard to follow in that code, I always get confused when reading it.

@BoxyUwU has been tweaking the release note generation tooling I think, so may have alternative ideas. I think in principle that tooling could do the process above and scan rust-lang/reference and/or support rust-lang/rust tracking issues pointing at the reference, but I think we still need 90% of the above implemented since milestoning those tracking issues is otherwise difficult.

[BoxyUwU]

I can take a look

[ehuss]

I can take a look at some of the triagebot stuff, it should be relatively simple (I did the cargo side for example).