Backport handling improvements

[bkchr]

Backporting also already partly automated via the bot and that works okayish. However, prs are staying in the queue for some time and can only be merged by the release team or something like this. I don't see any reason why these prs can only be approved by the release team. These prs should be actually merged almost automatically if all tests are green. I think we should also push to crates.io more often and not wait for random dates. Having fixed dates for binaries is reasonable, but for libraries that get consumed it isn't that useful IMO. Once per day we could release the changes to crates.io to not do too many pushes or once peer week, but clearly more than once every x weeks. As the backports are also only patches/fixes that shouldn't be causing any problems downstream.

To make this happen, we need the following:

• Ensure that CI is working in the stable branches. Right now it is most often failing and that should be prevented.
• Change the flow to merge automatically if the backport is basically a verbatim copy of the original reviewed code or require one review if there is more than one commit in the backport pr.
• Release the changed crates every X days from the stable branches.

[acatangiu]

I fully support this! 👍

Ensure that CI is working in the stable branches. Right now it is most often failing and that should be prevented.

This is the most important piece, up until recently it was not working at all, but from what I've seen recently it's now (mostly) working. Just need to get it to the finish line.

[ggwpez]

CI should 100% be green. And all changed be pushed back to the release branches. Currently we dont even have the exact files that were published.

The daily releasing to crates-io could be done, but is currently bottelencked on the automation thereof (and people to automate that) - hence the monthly patches.

[EgorPopelyaev]

I agree, the backports to release branches should have less strict review rules then the normal prs, as they were already reviewed. Probably one should be enough in case there are some conflicts or bigger changes.
I have another question here, what should we do then with the github releases for the previous stables in case of the more often crates releases (as we also discussed before in the coordination chat, that the binaries publications should be dropped for old stables and kept only for the actual stable and it's patches)? Should we drop then the github releases for the old stables completely, or accumulate these releases and publish the summary once a month for each release as we did before?

[ggwpez]

as we also discussed before in the coordination chat, that the binaries publications should be dropped for old stables and kept only for the actual stable and it's patches

I am not convinced of this. Pierre mentioned rollouts a few times and to me this means to have old binaries running as well. So that instead of all validators updating to a new binary, only a fraction does, and we roll out versions gradually.

I will try to get some clarity on this.