Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.56%. Comparing base (128f30b) to head (ce3a154).
⚠️ Report is 1 commits behind head on 9.0.

@@            Coverage Diff             @@
##              9.0    #2731      +/-   ##
==========================================
- Coverage   72.64%   72.56%   -0.08%     
==========================================
  Files         128      128              
  Lines       71241    71241              
==========================================
- Hits        51751    51697      -54     
- Misses      19490    19544      +54     

why do we need to open a separate PR to backport it? Marking the project label?

@enjoy-binbin We don't have to do this, but if we do it then we don't need to cherry-pick it. It is more useful if there is a large merge conflict or if the PR needs to be rewritten much.

What bothers me is that some commits are doing this and some are not.

This one we can see is absolutely no problem (no conflict at all) with the pick, so what strategy do we base this on? Everytime a PR marked with the project, we ask the author to open a new PR to do the backport and review it?

I still like this way: we pick everything into a final release PR so everyone can see which commits are included in the new release. Some commits are in the release notes, while others are not, but they are visible in the release PR.

I do agree the conflicts is painful, but that is something we always need to deal with (I just hope.

I still like this way: we pick everything into a final release PR so everyone can see which commits are included in the new release. Some commits are in the release notes, while others are not, but they are visible in the release PR.

We have discussed this sometimes in the past that it is too much manual work to make a patch release. Sometimes, the patch release has been delayed a long time because there are conflicts and also failing tests in the release branch. Therefore, we have discussed to make the backporting more proactively, maybe even create some bot that can open backporting PRs.

For example, this one: #2210 it was originally meant to be 8.0.4 but then there were some CVE fixes that had to be release quickly, so they were released separately in #2316 and the ongoing backporting PR was ignored. Finally, I finished that big backporting PR and completed the released more than two months later with new number 8.0.5.

We had a lot of conflicts before because we were doing a lot of formatting/refactoring related stuff. Can the robot handle conflicts well? I don't think so...

So it either relies on the author to rewrite it, or relies on other senior maintainers to deal with the conflict. We can ask for help, let the author init the backport PR against the release PR.

Anyway, it is indeed a burden, do what you think is right.

By the way, the test also exists in all the release branch (8.0/8.1)

By the way, the test also exists in all the release branch (8.0/8.1)

Oh! I only saw #2672 was marked To Be Backported in 9.0, so when I merged this PR I changed it to Done.

If we want it to be backported to 8.0 and 8.1, we must mark it for 8.0 and 8.1 projects To Be Backported. Otherwise we will forget to backport it.

Anyway, it is indeed a burden, do what you think is right.

I think we can do a mix of both ways, but if we do separate backport PRs like this one, they need to include the release notes changes too in the same PR (if they need release notes, but this one doesn't), to make sure we don't forget those release notes and we move it to Done. Later, when we do the release, we handle all the PRs that are still marked as To Be Backported.