Release notes: 2 level of changelog

[aaruni96]

Fixes #4665

---

Note: I am also using this PR body as my testing ground for my solution to #4673 . Everything in this comment after this line can be ignored for any other use.

---

Release Notes

• Does abc {package: AbstractAlgebra, renaming}
• Does 123 {package: Nemo, documentation}
• Questions 42 {package: Singular, serialization}

[aaruni96]

PRs like #5065 and #5186 only have one label for topic, and no secondary label. The script in its current form does not deal with this, and these PRs are excluded from the changelog.

Two options for dealing with this :

• introduce a "general" subsection where we put such PRs
• enforce all PRs to have at least two labels, one for the main section, one for the subsection

Which one do we want? Or do we want to do both ?

[fingolfin]

Aaruni and me discussed this last week, and my stance was "I don't care if we automatically put things into a "general" subsection or enforce two labels, as long as we don't "loose" PRs due to insufficient labels". My understanding is that this now got implemented by essentially enforcing "two labels" (i.e. a primary and a secondary label), and anything that doesn't have both will be flagged ?

[fingolfin]

Regarding progress on #4673: very nice! Though it's still missing support for specifying "additional labels" in the text.

[aaruni96]

and anything that doesn't have both will be flagged ?

Yes. The current implementation dumps things without two labels at the end, marked with a "TODO". Then manual work is required, either to re-label the PRs and re-run the script, or, to move things into a "general" category by hand.

[fingolfin]

Why is that a "prtype" and not a "topic"?

[aaruni96]

In PR like #5246 , you have both serialization and topic: polyhedral geometry. So, in the multilevel changelog would put it under "Polyhedral geometry", and the subheading "serialization".

If we put serialization in topics, then one of these labels will be ignored (script puts a PR in the first topic which is matched)

[fingolfin]

This is ready from my POV. I'd merge it, if not for the upcoming 1.5 release -- @lgoettgens @benlorenz would you prefer we wait this after the merge (just in case it breaks something), or should we merge now?

[lgoettgens]

I would prefer to wait until after the release, as I already checked the manual work needed for the release notes with the current setup. And I don't know how much changes with this change

side point: this PR has conflicting labels

[benlorenz]

I would also prefer to wait until after the release.

[lgoettgens]

The changes from this PR should also be reflected in the respective docs at https://docs.oscar-system.org/dev/DeveloperDocumentation/changelog/.