I read an article which can be found in full here. Below is an edited version of that article.
WordPress lead developer Andrew Ozz recently published a proposal for the addition of a new “gutenberg-merge” ticket type that would formalize the latitude Gutenberg contributors have been given for committing code after the Feature Freeze during the release cycle.
Normally, any new features and enhancements landing in the release are required to be committed before Beta 1 so they can be ready for testing during the beta phase. It used to be the case that tickets could be changed from “enhancement” to “task” right before Beta 1 as only a rare exception for items that were not ready in time for beta and just needed a few more days to get the go-ahead to be committed.
“The intent was to allow another two or three days, not a week or two. This exception used to happen quite rarely, perhaps a few times per year. However lately this exception has become part of the standard release workflow. In recent years, it’s become common for 15 to 20 tickets for code coming from Gutenberg to be changed to tasks each release. The reason they are changed is not to give the developers a few more days to complete them. It is mostly to signify that they are going to be committed later.”
Ozz said
Ozz claims that because the Gutenberg feature plugin is used on 300,000+ sites, including WordPress.com, and because 60% of users rapidly update to the latest version, that any features and enhancements coming from Gutenberg have already been tested.
The comment section of the proposal is active with varying opinions. Several of the participants in the discussion did not agree that just because features are in the plugin does not mean that they have been adequately tested against the goals they were intended to achieve.
“Something that worries me about how this could work is, that currently the level of documentation for features that land in core have a higher standard than Gutenberg merges. Once we approach the beta 1 time the documentation team goes through all the features that were merged in that cycle, making sure there are dev notes for any changes that might impact users / developers. If this deadline is shortened this also means that it may become harder to uphold this standard.”
Core contributor Fabian Kägy said
Kägy also noted the challenges of plugin and theme developers testing their extensions against core in order to ensure compatibility with the latest version.
“With this changed workflow the actual amount of time where you know with a pretty large likelihood what features will be part of a given core release becomes shorter, making it more difficult to ensure compatibly with a release in time of the release.”
Kägy said
Core contributor Peter Wilson outlined two concerns he has with the proposal:
- by treating Gutenberg as a special case, it will increase the conflict between those who primarily work in the WordPress-Develop repository and those who primarily work in the Gutenberg repository,
- bypassing the feature freeze requirements for the editor goes against the contention that Core is Gutenberg and Gutenberg is Core.
Wilson said the late merging of Gutenberg features has “been a source of conflict for several years.”
“Bulk merges of Gutenberg features late in the cycle have also been an issue reported from both those who work primarily in the Gutenberg repo and those who work primarily in the WordPress-Develop repo. For years incremental merges during the cycle have been advocated but never achieved per the comments in the linked post.”
Wilson said
Wilson also disagrees with the proposal’s statement that features developed in the Gutenberg repository are better tested in the feature plugin, as the goal of the Beta and RC periods are to test the release as a whole across many sites with different configurations.
“With Gutenberg as a plugin replacing core blocks with the plugin’s versions, testing the release as a whole doesn’t happen until after the editor changes merged in to WordPress-Develop. It’s only once Gutenberg is merged in to WordPress-Develop that the unit tests start running on various hosting providers running the test suite in a range of environments.”
Wilson said
WordPress Core Committer Joe McGill encouraged the authors of this proposal to elaborate on the policies and expectations that will be applied to committing patches to tickets designated with the new ticket type.
“For example, should all of these commits be completed before RC-1, unless a bug is discovered during the RC period—and only the fixes discovered be committed, or are there other rules in play? Personally, I still think that we should aim to have code for any major new feature merged before the Beta-1 milestone, regardless of whether it’s being tested in the Gutenberg plugin or not.”
McGill said
The discussion is still ongoing in the comments of the proposal. Although the proposed changes primarily affect the core contributors, committers, and release leads, they also will have an impact on the testers and WordPress’ plugin and theme developer community working to ensure compatibility ahead of a major release. Those who have feedback on how Gutenberg features are handled during and after “feature freeze” should jump in on the comments of the proposal to have their voices heard.
Leave a Reply