scripts/release-notes: new category "cluster virtualization".

[knz]

Epic: CRDB-29380

The category cluster virtualization (aliased to multi-tenancy and virtualization) encompasses changes to our cluster virtualization and multi-tenancy infrastructure that have UX surfaces: SQL syntax, cluster settings, etc.

This includes changes only visible to SREs.

Release note: None

[cockroach-teamcity]

This change is 

[knz]

NB I also have updated https://wiki.crdb.io/wiki/spaces/CRDB/pages/186548364/Release+notes already.

[mikeCRL]

Thank you! A few considerations I'd like to raise:

1. We'd additionally discussed the idea of pushing these RNs to our new [future] doc page instead of the main release notes page. Alternatively, we could leave these RNs in place, and just add a one-line explanation under the heading, linking to our new page. Either way, that can be a follow-up decision and PR prior to the first alpha. FYI @amruss @lnhsingh.
2. From the PR description, "This includes changes only visible to SREs" conflicts with this wiki section. Thoughts? (Is this intended as a temporary exception, or are we really doing that across the board, in practice, despite the wiki, and this is in keeping with that? Regardless I have plans to review RN content/policy soon. We can confirm and clarify what we want to say for this PR/wiki edit, and then revisit later.)
3. Regarding release-notes.py, it looks like we are no longer using the one in the cockroach repo and are exclusively using the one we have in the ed-tools repo. I'll ask @nickvigilante to coordinate with you on getting these changes in the ed-tools copy and removing the original cockroach copy. Nick, note that the two latest commits affecting the file in cockroach came after you brought the file into ed-tools, so they should be revisited for potential inclusion. Can you please help with this?

Can we get additional Docs/PM approval before this change is made? Adding reviewers.

[nickvigilante]

One issue, but LGTM otherwise!

[knz]

1. We'd additionally discussed the idea of pushing these RNs to our new [future] doc page instead of the main release notes page. Alternatively, we could leave these RNs in place, and just add a one-line explanation under the heading, linking to our new page. Either way, that can be a follow-up decision and PR prior to the first alpha. FYI @amruss @lnhsingh.

Agreed. One advantage I see of having the script scrape this new category is that it clumps all the related RNs together so we can more easily copy (or cut) them and paste them elsewhere.

2. From the PR description, "This includes changes only visible to SREs" conflicts with this wiki section. Thoughts?

Yes the guidance is clear: if a product change applies only to an internal user group
The purpose here is that if a change only affects CC (internal to CRL) and only affects CRL staff then it doesn't deserve a release note.

But a change that affects SElf-hosted, and SREs for self-hosted cluster should get release notes. That's what the "ops change" category is for really (for non-multitenant stuff).

Can we get additional Docs/PM approval before this change is made? Adding reviewers.

Discussing this with Abbey today.

[knz]

From the PR description, "This includes changes only visible to SREs" conflicts with this wiki section. Thoughts?

I took the liberty of updating the wiki page to clarify this.

[lnhsingh]

This LGTM, with the assumption we'll decide where these release notes live in a future discussion.

[knz]

Thanks. @nickvigilante what's your stance on this? You have a blocking review.

[nickvigilante]

Approved with one change.

[knz]

Cheers!

bors r=lnhsingh,nickvigilante

[craig]

Build succeeded:

• Bazel Essential CI (Cockroach)