Consider release tooling that doesn't involve forwardporting commits to main

[jacobtylerwalls]

I appreciate the hard work that's gone into the current release procedure. I'm trying to learn it as best I can so that we at least have a couple folks who are comfortable doing it. (I think @DanielNoord has expressed reluctance before to review release PRs.)

It's not getting any easier for me, even after doing a few pylint and astroid patch releases. Merging and rebasing is not the problem; I do that all day. The problem is there being so much churn on the main branch when forwardporting the maintenance commits.

Why would we want commits like this one on the main branch? My instinct is that I'm doing something very dirty, and every time I look up the prior pull requests to verify "no, this is what's expected...".

If the answer is just it makes pre-commit autoupdate happier, then I'd like to gently suggest finding a better tool, or finding a better way to use it. 😄

If the answer is I botched the merge, then I just want to suggest that we had two sets of eyes on it in #9297 and #9299 and still approved everything. 😅

Other python projects I've worked on have had dramatically simpler approaches to managing the main branch.

I'm volunteering to look into some alternatives, if that would be welcome. I think the outcome I'd like is that multiple people feel comfortable releasing, and I don't think we're at that point right now.

[DanielNoord]

I think the main issue we have is that we need to make sure that the news fragments that are assosciated with the patch release are also marked as such on the main branch. Ideally using the same commit, but that's where the issues start probably.

I'm also fine with never merging maintenance into main, but I don't immediately know how to do the release notes a little better.

[Pierre-Sassoulas]

Thank you for opening this issue, I thought about releasing more frequently but the release procedure is arduous (even if we did that in 2.15 and it's actually a major improvement already).

We could satisfy pre-commit autoupdate with a "fake" merge commit (git merge maintenance/3.0.x -s ours --no-ff done from main). Doing that we would not recover change we want to actually merge, afair:

• the fragments being deleted from the maintenance branch
• the change to the CONTRIBUTORS.txt.

Solutions:

• For CONTRIBUTORS.txt we can generate a more accurate contributors.txt on the main branch automatically with python3 script/create_contributor_list.py.
• For the list of deleted fragments, they could be recovered with git diff --name-status main|grep "doc/whatsnew/fragments/" (launched from the maintenance branch) and deleted with a rm pipe or some python scripting every contributor could understand.

Then it's just a matter of automation to amend the fake merge commit. There's a list of things that would make release easier in #7362 too.

[Pierre-Sassoulas]

Alternatively looking into how it's done in other repos would probably be good, ruff's release are pretty nice (and very frequent) https://github.com/astral-sh/ruff/releases.

[jacobtylerwalls]

Struggling with this again in #9903.