[wp-trac] [WordPress Trac] #64393: Change how we include Gutenberg in Core

[WordPress Trac]

#64393: Change how we include Gutenberg in Core
------------------------------+--------------------------
 Reporter:  youknowriad       |       Owner:  youknowriad
     Type:  task (blessed)    |      Status:  reopened
 Priority:  high              |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:
 Severity:  blocker           |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+--------------------------

Comment (by dmsnell):

 Here’s a pragmatic proposal: what if we introduced a weekly cadence on
 this one in order to make it easier to find all the places that are broken
 but without obstructing everything in the meantime?

  1. Immediately revert the entire chain of patches on this issue. This
 will restore `trunk` to a working state. Unfortunately this involves
 resolving merge conflicts in `Global Styles: Lift classic block
 restrictions.` [https://github.com/wordpress/wordpress-
 develop/commit/31e2aaabbafa6eaf32801c555747de4beb90b6d9 31e2aaabb] because
 of indexing in `$submenu`, but this is the point of the revert. The more
 we keep adding ad-hoc patches to work around the issues the harder it is
 to isolate the changes and the unintended damage they are causing.

 2. Liberally update the build change in a separate branch. Everyone is
 encouraged to merge this branch into their local development and report
 issues on this ticket.

 3. Every Tuesday we merge the `build-change` branch into `trunk` and see
 if new reports turn up. If they do, we revert the change again and attempt
 to fix the issues in the `build-change` branch.

 This will add a number of merge/revert commits in `trunk`, but under the
 principle of //don’t break `trunk`// it helps to prevent this change from
 obstructing everyone else’s ongoing work. It also means that once the
 change has been sufficiently vetted, tested, and corrected, then it will
 have a single commit where it can be analyzed as a whole. Right now it’s
 already getting hard to understand the scope of this change and the
 impacts. For example, in [https://github.com/WordPress/wordpress-
 develop/pull/10718 PR#10718] there is a change to the `.gitignore` file,
 but because it’s a single commit on a chain of changes, the `diff` view
 doesn’t show whether the relevant PHP files are still in the `.gitignore`
 or not.

 I really appreciate the energy going into this to make the Gutenberg sync
 easier! We still have ample time before 7.0, meaning we should feel no
 duress to rush hastily. I want this work to continue, but I hope we do so
 thoughtfully, considerably, and without breaking Core (doing things like
 skipping security processing by default does not seem to align with those
 goals either).

 Personally I do all my development in a long-running stacked branch which
 merges multiple in-development branches together, now including a revert
 of the entire patch-series for this change. I don’t experience any
 meaningful trouble by maintaining this branch and would be happy to help
 anyone who is worried about fixing things in a long-running side-branch so
 that we can have a stable and atomic commit in Core when this change is
 ready.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64393#comment:73>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform