Forward port release notes changes from stable/1.0

[mtreinish]

Summary

In the rush to get 1.0.0rc1 release on time, we missed migrating the release notes from the root of the notes directory to the 1.0/ subdirectory. Doing this is convenient because it makes it easier to associate notes with a particular minor/major release which is useful for navigating potential issues with reno's history scan. This commit forward ports the state of the stable/1.0 branches release notes to main. This will make it much easier to differentiate which release notes are associated with 1.1 instead of 1.0.

Details and comments

This is a partial forward port of #11760 all of the changes made here were part of that PR. #11760 just included larger changes to prepare the 1.0 release so this PR wasn't done with a normal cherry pick or via the mergify bot to avoid porting over the unnecessary pieces of #11760.

[qiskit-bot]

One or more of the the following people are requested to review this:

• @enavarro51
• @Qiskit/terra-core
• @ajavadia
• @ikkoham
• @levbishop
• @mtreinish
• @nkanazawa1989
• @t-imamichi

[jakelishman]

The file diff looks right, but all these release notes have the subcategories we use in the prod docs deployment, but don't typically have on main. Do we want to add the categorisation config file to main as well?

[coveralls]

Pull Request Test Coverage Report for Build 8100530390

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 4 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.02%) to 89.304%

---

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/lex.rs	4	92.19%

Totals
Change from base Build 8097968633:	0.02%
Covered Lines:	59121
Relevant Lines:	66202

---

💛 - Coveralls

[mtreinish]

The file diff looks right, but all these release notes have the subcategories we use in the prod docs deployment, but don't typically have on main. Do we want to add the categorisation config file to main as well?

Oh good catch, yeah we should add the categories. We weren't doing that because previously we had avoided adding a git version of reno to the requirements-dev.txt file on main. The risk is if anyone is using a released version of reno they'll hit an error because the config syntax for categories isn't supported on a reno release yet (let me ask on IRC if there is any appetite for a new reno release soon).

[jakelishman]

This looks ok to me. It's going to turn reno new --edit into a nuisance to use for a bit, I think, because there's going to be like 200 sections in it to delete.

Two thoughts:

1. We might need to advertise this change to Qiskit developers, including potentially updating the contributing instructions?
2. Ought we to section the release notes that have merged to main since 1.0 but aren't being backported in this PR, or shall we do it in a follow-up?

I'm somewhat keen to get the sectioning done at the point of merge - it's less work to do at the time of a release.

[mtreinish]

This looks ok to me. It's going to turn reno new --edit into a nuisance to use for a bit, I think, because there's going to be like 200 sections in it to delete.

Oh that reminds me we maybe need to add a template section to the config to document the contents of each section. For an example see experiments: https://github.com/Qiskit-Extensions/qiskit-experiments/blob/main/releasenotes/config.yaml#L38-L110 Although would just make the number of lines to delete even bigger.

We might need to advertise this change to Qiskit developers, including potentially updating the contributing instructions?

I think we can do this in a follow up too. I was hoping to keep this PR mostly mechanical as ensuring the changes we made to release notes from stable/1.0 are reflected on main too. We can push up a PR in parallel updating the contributing guide in parallel.

Ought we to section the release notes that have merged to main since 1.0 but aren't being backported in this PR, or shall we do it in a follow-up?

I think lets do this in a follow up.

[jakelishman]

Yep, I'm fine with that and on board with doing both in follow-ups.