Remove 90% of the last-minute effort required to backport PHP changes to wordpress-develop

[adamziel]

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

[noisysocks]

For changes to existing features that exist in Core this makes sense but I'm not sure how it would work for new or experimental features. For example, if I open a Gutenberg PR that changes something about the Navigation screen, I can't open a corresponding Core PR because the Navigation screen doesn't exist in Core.

[draganescu]

It could work for new code as well, if we want that new code to land in the next version you could open the PR that adds the code in the correct core place.

[anton-vlasenko]

In my opinion, the solution proposed by @adamziel is totally valid.

We had the same process on one of the open-source projects I was involved in.
There was a requirement to create a separate PR to backport the changes to the open-source version of that project each time we submitted a PR to the "commercial" repository of the project.

Speaking of WordPress, there must be a requirement to backport changes from Core to Gutenberg too.
There are only three such issues in the Gutenberg repository :( https://github.com/WordPress/gutenberg/issues?q=is%3Aissue+label%3A%22Backport+from+WordPress+Core%22+is%3Aclosed

[noisysocks]

It could work for new code as well, if we want that new code to land in the next version you could open the PR that adds the code in the correct core place.

Yes but you would have to keep track of all previous wordpress-develop PRs regarding the experimental feature and base your new PR off the most recent PR. I'm not sure how practical that is. To clarify, I'm talking about long-running experimental features that require hundreds of PRs e.g. navigation screen, widgets screen, site editor.

[draganescu]

I'm talking about long-running experimental features that require hundreds of PRs e.g. navigation screen, widgets screen, site editor.

But these are experimental in gutenberg not in core. They land in core once, and that's when the core PR should be done.

[michalczaplinski]

I really like this proposal !

As the Editor Tech Co-lead for 6.1 together with @ockham we'll keep a close eye on it 🙂

[adamziel]

@michalczaplinski feel free to take the lead here - as the release lead you are well positioned for that!

[michalczaplinski]

Thanks @adamziel. And, yes, that's what I meant to say 😄 We'll keep a close eye on the problems you mentioned and based on what we'll encounter I hope we can champion this proposal!