3.12 changelogs updated (backport #9908)

[mergify]

We need this since we backported PRs after changelog was first generated

• Patches conform to the coding conventions.
• Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions). no

Needs a forward-port to master.

---

This is an automatic backport of pull request #9908 done by [Mergify](https://mergify.com).

[mergify]

Cherry-pick of fd82dbe has failed:

On branch mergify/bp/master/pr-9908
Your branch is up to date with 'origin/master'.

You are currently cherry-picking commit fd82dbe7f.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	deleted:    changelog.d/issue-9578
	deleted:    changelog.d/pr-9583
	deleted:    changelog.d/pr-9813
	deleted:    changelog.d/pr-spdx

Unmerged paths:
  (use "git add/rm <file>..." as appropriate to mark resolution)
	deleted by them: changelog.d/issue-9736
	deleted by us:   release-notes/Cabal-3.12.0.0.md
	deleted by us:   release-notes/WIP-cabal-install-3.12.x.0.md

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

[geekosaur]

Was backport the right way to do this? I don't think we want it deleting changelogs for PRs landed in master after 3.12 was branched.

[ffaf1]

Then we would have duplicate entries in release notes, am I wrong? (e.g. one on Cabal-release-notes-3.12.md and one in Cabal-release-notes-3.14.md)

See last sentence in Making a release “C.2 CHANGELOGs” section.

[geekosaur]

No, it looks like it wants to delete the changelogs for everything committed to master after 3.12, so we would be missing the changelogs for those.

[geekosaur]

Never mind, spot checks suggest those are just delayed backports and indeed should be deleted.

I am left wondering how to fix the conflicts, since they're whole-file changes instead of commit markers. Mergify's a bit confusing.

[ffaf1]

Yes, next time we will do the sensible stuff and produce a changelog after everything is backported.

[Mikolaj]

I am left wondering how to fix the conflicts, since they're whole-file changes instead of commit markers. Mergify's a bit confusing.

Normally, with git, I'd git reset, git add the few files that are not deleted and create a new commit with the old name. Would then pushing -f convince mergify it's resolved? Actually, do we care what mergify thinks? I wouldn't be surprised if it doesn't mind merging commits with conflicts as long as CI passes. In fact, I think, it did in the past causing us grief. :)

[Mikolaj]

Hmm, but that solves only this single failed cherry-pick, which is a part of the big rebase. So I think I'd rather make the whole rebase locally, resolving this conflict and letting rebase continue, and push -f the result to this PR.

[Mikolaj]

And I'd first locally squash the 2 commits in #9908 so that the big rebase is just a single cherry pick of the squashed commit onto the master branch. Makes conflict resolution easier.

Does it make sense?

[ffaf1]

The culpirit is #9810, which modified changelog files that we already deleted in 3.12. I am going to open a new PR which should simplify this.