#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):
> Perhaps a middle road is to version control some of the files again, I
don't really know if that would fix everything.
@ellatrix I think there is a misread if you find anyone arguing against
making Gutenberg updates smoother. This middle ground is conflating two
related issues.
- The PHP files necessary for booting WordPress were removed from
`wordpress/wordpress-develop` which is the primary cause of breakage in a
number of workflows that probably weren’t familiar when this change was
merged.
- The version history for those files was also removed via `.gitignore`
which makes historical analysis, debugging, and understanding harder. That
doesn’t lead to the immediate breakage, and it’s understandable how
someone who doesn’t rely on that information might underestimate how
important it is.
My proposal that I’m working on in [https://github.com/WordPress
/wordpress-develop/pull/11024 PR#11024] is primarily about these two
factors, specifically the first one. While we can restore those files
(which will prevent the breakage), we sadly cannot restore the continuity
of the source versions. We can preserve it going forward though.
This has been my primary call to action throughout this entire thing:
- these workflows were broken by intentionally removing required files.
- removing these files was not required to accomplish the change in this
ticket; and adding them back doesn’t impede the change in how Gutenberg is
sync’d
- let’s add them back, even though we cannot fully restore what was lost.
The work in [https://github.com/WordPress/wordpress-develop/pull/11019
PR#11019] is related but focused on addressing the ways that build step
has impacted working on `wordpress/wordpress-develop`. In combination with
bringing the files back it helps restore broken workflows.
----
I just want to reiterate that there’s been broad support for making the
sync easier; and as far as I can tell, of eliminating the package process.
If I have communicated that I think this shouldn’t move forward in any
way, then I apologize, but I have tried hard to only ask that the way in
which we move it forward is considerate of the people it affects and aware
of the complicated and sensitive nature of a change this big. It’s too
late to revert; it’s too late to get back the (easy) source history for
these files, but it’s not too late for the process mitigations.
There was one more idea I had in the back of my head that I want to try,
which might restore version history if we make some allowances in the
repo, but primarily I just want to ensure that WordPress continues to run
where it’s currently broken.
Docs generation is a good example of that. I wish the documentation
generation process were smooth and clear and testable and widely-
understood, but it isn’t. We //barely// got the docs at
developer.wordpress.org updated //after almost two and a half years of the
process being broken//, and it’s immediately broken again with WordPress
7.0 because of the required build step, and broken in a way it wasn’t
broken before this change. I think those docs are valuable to people; I
hate that they were stale so long; I hate that we didn’t step in sooner to
fix them; and I hate that we have to do so much more work now to try and
figure out how to make this deeper change on a system nobody seems to have
knowledge of anymore.
Nobody will be able to see the docs for the new AI client until we figure
out how to fix the docs-generation system to run the build step.
Or we restore the files that didn’t have to be removed. That’s where I’m
coming from. I can buy the philosophical goals of removing those files,
and I can sympathize with the work of maintaining the sync, as I have
personally maintained a number of files on both repos and dealt with the
technical and social challenges involved there. There are 100 other
systems broken because of the build just like docs — it seems like the
host tests are another example of that.
None of this is about Gutenberg sync, or the change itself. This is all
about middle ground and figuring out if we can accomplish the intended
goal without causing harm to everyone else. And yeah, an early revert
would have made this so much easier for everyone because the change could
have been isolated, but that’s water under the bridge now because it can’t
be undone.
I hope that there will be lessons we can learn though from it: to be
quicker to revert changes when people report breakage; to better
understand the far-reaching impact that basic changes like this have on
the broader WordPress ecosystem; and to //never// remove and `.gitignore`
files that remain part of the WordPress distribution.
This highlights something I brought up back at WCUS — it would be nice to
try and adopt the RFC system PHP uses for big changes. As @desroj
mentioned, it can be hard to draw attention to major changes like this
when there is so much broader activity going on. It’s even harder when a
change is controversial to build alignment and move forward. I do think
that having more formality around changes that affect everyone would
lesson the personal impact this ticket has caused, giving everyone more
time to notice the proposal, have a clear deadline for when the author
expects it to move forward, and to allow everyone with quorum an
opportunity to vote or request changes.
----
This is a hard multi-year process. I wish it were simple. Props to you and
@youknowriad and everyone working on it.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/64393#comment:170>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform