@francina facilitated the chat on this agenda.
@valentinbora took care of publishing the meeting summary with special thanks to @amykamala, @audrasjb, @Cenay and @marybaum.
Full Meeting transcript on Slack
This devchat marked week 7 of the 5.4 release cycle.
Announcements
Upcoming Releases
Release Candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 1, scheduled for March 3rd (read more about the WordPress 5.4 Development Cycle)
WordPress Release Cycle
For background, please read:
@johnbillion got to the heart of the matter: should beta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. be for fixing bugs that predate the ones introduced during alpha?
@jeffpaul shared his experience since version 4.7: beta is for any bugs, but the release candidate is for regressions only, even though the handbook doesn’t specifically point one way or the other.
@johnbillion liked the idea that beta is for every bug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority., as long as it’s in the milestone. But he noted that could make things tough in shorter release cycles.
@jeffpaul pointed out that avoiding committing non-regression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. bugs during beta means Beta and RC wouldn’t be as clearly different from each other as they are now. Potentially, they could merge into a single term.
@johnbillion averred that bugs could still get fixed in beta, but RC should be the point where the Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team is happy to release.
@joemcgill confirmed the current release cadence is set to assume that bug fixes of all types happen during the beta period (with digression from committers about what is safe to commit).
@joemcgill @johnbillion @azaozz all liked the idea of branching earlier in the cycle — for instance, at beta 1 — so people can keep working in trunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision., and @sergey confirmed things typically go pretty smoothly on that end. He also favors branching as soon as the current milestone is empty.
per @johnbillion, @matt has, in the past, preferred to keep focus on the current release.
@joemcgill stressed that the core team needs more clarity on what types of fixes are appropriate to commit to the 5.4 release, pointing out that the discussion in chat echoes this proposal to review historical practices to improve the project and potentially speed up release cycles.
@francina referred the group to the Release Model Working Group Chat Summary: February 19th, 2020 for the latest on that proposal.
@joemcgill and @francina — with other voices chiming in from the group — confirmed that 5.4 will continue as planned, with no changes. Any changes the working group comes up with will be effective no sooner than with the 5.5 cycle.
Components Check-in
- News from components
- Components up for adoption (Filesystem API and Rewrite Rules)
- Components that need help
- Cross component collaboration
@francina proposed a change to the Components Check-in.
Up to now it’s typically fallen towards the end of the chat, so it feels rushed and rarely leaves enough time to dig into topics the group might bring up. She offers two options:
- Schedule a weekly post in Make, where maintainers can leave a status update, like the one for Community deputies;
- Adopt a Slackbot that, once a week, asks maintainers for a status update.
@francina also proposed that those updates — and other communications — live in a new #component-maintainers Slack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel. Core is getting very busy with automated updates like Trac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. and Travis bots, plus RSS.
@valentinbora observed he hasn’t seen many check-ins in past meetings. @francina surmised that maintainers might not have time [to meet], or that time zones and other commitments [could be sources of conflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved.].
@francina and @valentinbora agreed that going async [communicating asynchronously] could help.
@cenay was in favor of the Slackbot option.
Action items
- @francina to collect all the different info streams about the development cycle, offer a window to comment and update documentation;
- @audrasjb to get all dev notes Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include:
a description of the change;
the decision that led to this change
a description of how developers are supposed to work with that change.
Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. by the end of the week and publish the Field Guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. before RC1.
Next Meeting
Meetings for #devchat take place weekly in the #core channel. The next meeting is Wednesday, March 4, 2020, 21:00 UTC.
#5-4, #component-maintainers, #core, #dev-chat, #meetings
