What problem does this issue want to solve?

Releasing WordPress requires investigating all the Gutenberg PHP changes made since the last release.

Me and @gziolo led that effort for the 6.0 release. It was hard, time consuming, and the mistakes turned into stressful last-minute fixes. And I mean not for just us, but also for the authors of the related PHP changes.

We believe there's a way to make this process faster, more reliable, and less stressful for everyone involved.

What effect does this issue want to achieve?

Here's what the process looked like for us. Let's find a way to remove or simplify as many steps as possible:

• Identify the candidates for backporting
  • Find all the PHP files changes since the last release
  • Find all the merged Pull Requests that changed them
  • Narrow down to ones that haven't been backported yet
  • Take note of all the authors, files, status
• Ask the authors which changes have to be backported
  • The authors had to time-travel a few weeks or months back to remember the context
• Ask the authors to prepare the backports
  • The authors had to remember even more of the context and nuances to prepare the backports
  • The time before Beta 1 was relatively short, making this more stressful than necessary
  • Some authors couldn't due to high workload, fever, or other circumstances
• Review and merge all the backporting Pull Requests
• Publish any backports that were still missing at this point
• Test, find integration bugs, track them down and fix them with a last-minute effort

What solution does this issue proposes?

One solution would be to require creating a backport PR before merging any PHP changes into the Gutenberg repository. Note I mean specifically creating the backport PR, not merging it. It could just sit there, reviewed, and wait for the release.

Why? It will never be easier:

• The author has all the required context fresh in their minds.
• The author is not AFK and has the required availability.
• The PR has the reviewers' attention.

Conflicts will happen, but that's okay. Resolving conflicts later on is much easier than executing the entire backporting process.

But it would create a speed bump for merging Gutenberg changes

That speedbump is already there, it's just invisible until the release. Requiring a backport early would actually make that speed bump smaller – it wouldn't have any time to grow.

How? A CI check could be a good start. It would be red when no backport is mentioned in the PR description, or green when there is one. It's not a watertight system for sure, but perhaps it would suffice.

If there's a better solution, let's discuss that! I also remember @gziolo also had an alternative idea.

cc @peterwilsoncc @annezazu @priethor @noisysocks @mtias @Mamaduka @paaljoachim @hellofromtonya @oandregal @youknowriad @mcsf @scruffian @draganescu @getdave @desrosj @ndiego @costdev