Dev Chat Summary: March 7th (4.9.5 week 5)

This post summarizes the dev chat meeting from March 7th (agenda, Slack archive).

4.9.5 planning

  • @audrasjb and @danieltj to lead bug scrubs every Tuesday from 20:00 to 21:00 UTC
  • Planned release schedule:
    • Beta: 03/20
    • RC: 03/27
    • Expected release date: 04/03
  • Looking to move some 5.0 `good-first-bug` labelled tickets to 4.9.5 if they are already committed, self-contained, can be back-ported cleanly before milestoning, and don’t introduce any unintended backcompat issues

Definition of what’s included in minor releases && Gutenberg updates

  • @jbpaul17: Suggestion to expand what can go into minor releases and allow new files to be introduced as this could benefit projects being able to ship in a minor versus waiting for a major release/5.0 (e.g., serve happy, debug screen, on boarding improvements, GDPR compliance tools)
  • @jbpaul17: Question as to cons for doing so (e.g., breaking auto-updates) and whether they’re unsolvable technical problems or historical blockers that haven’t been researched recently and could potentially be resolved
  • Previous discussion on this topic related to inline docs
    • “Every extra file adds a significant amount of KB to the package, which adds up pretty quickly. This not only stretches the load balancers (when suddenly millions of sites are updating within an hour), but also each individual site, which must download the ZIP, which takes time (partial builds made things, on many shared servers, go from minutes to seconds) and introduces lots of possibilities of download failures, and thus sites needing to retry later (and wait longer) to get patched.”
  • Prior comment that although it’s a little inconvenient, it’s a handy line in the sand for backporting to prevent new files
  • @joemcgill: Important to get input from people familiar with and have access to the infrastructure and historical data about releases
  • Side conversation on altering version numbering scheme such that next major could be 4.10.0 and allow non-Gutenberg projects to land in a major release while Gutenberg can still have the 5.0 version number; alternative to switching to semantic versioning is pushing Gutenberg back to 5.1
  • @joemcgill: Important to clarify what we’re trying to solve: trying to release some new features that are blocked while we wait for Gutenberg/5.0. Suggestion: discuss the specific features and why they’re worth including in a minor and figure out the technical blockers to make that happen
  • @xkon: GDPR work is trying to avoid shipping with Gutenberg to ensure user-stress levels are low for these respective updates; in an ideal world GDPR should land before May 25th
  • @joemcgill: Helpful to understand the roadmap for 5.0 timelines to know if we should squeeze something in a minor release or do a vanity 4.9.10 major release
  • @matveb: Gutenberg plan is still tentatively April
  • @peterwilsoncc: Pushing new files into minors would require two releases:
    • 1 to update auto updates
    • 2 to update and include the new files for GDPR, serve happy, etc.
  • @sergey: precedent of adding new functions to existing files in a minor branch where they’re in separate files on trunk, same could apply for GDPR/etc.
  • @joemcgill: restating the problem… We have some features ready for release but are blocked by historical constraints on our minor release process, meanwhile we have no clear sense of when the next major is going to be ready because it’s tied to Gutenberg
    • Option 1: Change the constraints on a minor release and add the features. This needs input from infrastructure people
    • Option 2: Do a major release before Gutenberg is ready if we need to
    • Option 3: Wait for Gutenberg to be ready
  • Gutenberg team looking for more help in getting it ready for the path to merge proposal, getting a promo notice in a release to help increase testing
  • @azaozz: GDPR tools cannot wait very long. Will need to be out end of April, early May the latest
  • Gutenberg work divided into “feature complete”, “merge proposal” (things we definitely need), and “5.0
  • Gutenberg areas that need attention for 5.0 merge:
    • API tasks need owners.
    • All core issues should have corresponding tickets.
    • JS packages integration can be a topic for the core-js chats.
    • Gutenberg repo needs help with triage and fixing bugs.
    • Documentation and coding standard updates.
    • Accessibility needs to be improved
  • Various Gutenberg-related tasks could use help and don’t have to wait for merge proposal:
    • Various REST API tasks that can be done now in parallel
    • Core changes
    • New endpoints and infrastructure plans
    • How would inclusion of Gutenberg/JS packages work
  • Gutenberg team would like to see how integration with truck would work as early as possible, aiming for April for an initial merge/first beta (not actual 5.0 release)
  • Gutenberg team needs more component and lead developers focus and feedback

Next meeting

The next meeting will take place on March 14, 2018 at 21:00 UTC / March 14, 2018 at 21:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-5, #core, #dev-chat, #gutenberg, #summary