CI: Use backport service

[matthewturk]

At present, backporting PRs from main to stable is a manual process that requires considerable investment. This typically results in a large, labor-intensive effort to make a bugfix release.

I would like to propose that we install meeseeksbox, which is an automated system for backporting PRs. What we would do is install it, and then any PR to which the label backport is applied would catch its attention, and when it is merged, it would also be applied to the stable branch (in a new PR). When a conflict is detected, it does not go through, and gets flagged for attention.

Among other things, this also means we could bulk label things for backporting, and it would help us to keep a stable branch that was up to date and in a state of ready-to-release.

[neutrinoceros]

I'm 100% favourable to this.

[cphyc]

That sounds like a really good idea with a much smaller chance of human error! Just don't allow meeseeks to pop meeseeks.

[munkm]

it would also be applied to the stable branch (in a new PR)

Can we change branches that it issues PRs to? We modified our backporting process last release cycle so bugfixes will be on a 4.0.x release branch and stable will only be updated during major and minor releases.

[matthewturk]

Yes, we can -- it gets the info from the description of the label applied to the PR.

[neutrinoceros]

We modified our backporting process last release cycle so bugfixes will be on a 4.0.x release branch

excellent, this is exactly how matplotlib sets it up too

[brittonsmith]

In favor.

[neutrinoceros]

Note that as noted in #3555, back porting is safer if we manage to reproduce the merging of the original PRs
With this is mind, we should probably hold on deploying Mr Meeseesks as long as we're not done manually back porting the list from #3555, except if Mr Meeseeks can somehow be utilized to do it for us ?

[matthewturk]

I think we should try it by seeing if labeling a closed PR will result in it backporting. Which one do you think is the safest?

…

On Fri, Oct 15, 2021 at 3:11 AM Clément Robert ***@***.***> wrote: Note that as noted in #3555 <#3555>, back porting is safer if we manage to reproduce the merging of the original PRs With this is mind, we should probably hold on deploying Mr Meeseesks as long as we're not done manually back porting the list from #3555 <#3555>, *except* if Mr Meeseeks can somehow be utilized to do it for us ? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3553 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAVXO6WDJEHXZ3SS3DMENLUG7OZTANCNFSM5FZNT5BA> .

[neutrinoceros]

#3238, which happens to be at the top of the list, has 0 potential conflict with anything else, I believe :)

[matthewturk]

OK, sounds good. I'm going to install and we can try it out on that one.

…

On Fri, Oct 15, 2021 at 9:23 AM Clément Robert ***@***.***> wrote: #3238 <#3238>, which happens to be at the top of the list, has 0 potential conflict with anything else, I believe :) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3553 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAVXO5GCKGXQORTV4OCZO3UHA2NBANCNFSM5FZNT5BA> .

[matthewturk]

Well, seems like we don't need to install it.

I'm going to create a couple labels that are explicit about what to backport to:

backport-stable
backport-yt-4.0.x

[matthewturk]

Applying labels to closed PRs won't work. But, we can add to our mergable status that there has to be a label of "backport*" or "dont-backport" which would get us doing it regularly.

[matthewturk]

We can see this in action at:

#3238
#3570

I'm now issuing comments to all the PRs listed in #3555.

[matthewturk]

PRs that need manual backports will be labeled, but, closed: Still Needs Manual Backport

[neutrinoceros]

So we've been using this tool to semi-manually backport a couple dozens PRs in these last few weeks.
I works well, but it generated a massive amount of notifications over a very small time, and consumed many CI hours as well.

I guess the question that needs answering now is whether we'd like to switch to a continuous backporting workflow (which is also supported by meeseeksbox). It would basically have a similar cost in terms of activity (one backport per PR), but it would offer the following advantages:

• notifications would only be as frequent as bug fixes mergers (and it's always possible to mute specifically backport-related notifications)
• the backport branch would always be in a release-ready state, so we could decide to do a new bugfix release much more rapidly next time.

I would personally be favourable to this kind of workflow, as I think the gain outweighs the costs.

[neutrinoceros]

Continuous backporting was (sort of) rejected last time it was mentioned on the mailing list, and it looks like we're not doing a third bugfix release on the current backport branch after yt 4.0.2
I don't think there's any action left to take here so I'll close.