Hello all, Here are this week's docs team meeting minutes (short form). Details in [2]. Join us if you have interest in StarlingX docs! We meet on Wednesdays 12:30 PST.   [1]   Call logistics: https://wiki.openstack.org/wiki/Starlingx/Meetings   [2]   Tracking Etherpad: https://etherpad.openstack.org/p/stx-documentation thanks, Mary Camp ========== 120K max!! Copy over from etherpad, change format to Plain text, then futz with indents. OK to leave URLs. 21-Apr-21 . All -- reviews merged since last meeting:  8 . All -- bug status -- 18 total - team agrees to defer all low priority LP until the upstreaming effort is completed.  Status/questions/opens Release 5 Preparation - May 5th is the release target.   Docs are in progress for the R5 features.    AR Mary update the Release Notes  - Hardware update - bullet to point to this guide:   Node management guide: Configuring VF Interfaces rate limiting Using the CLI       Juanita will ask Greg if the appendix from their RN should be pushed upstream)  https://bugs.launchpad.net/starlingx/+bug/1925071  new LP to correct this guide: Configure Ethernet Interfaces on SR-IOV interface Using Horizon   Juanita will assign to new writer who is joining the team (Elisa)  Release Notes for R5 - should they use the |prod| substitution? Mary suggests the answer is No, since these are STX specific release notes, but would like team input.   The team agreed that today, we'll leave StarlingX hardcoded in the release notes. The WR team will investigate if needs changing to accommodate downstream efforts. Broken symlink issue w/downstreaming - Ron looked at it more, still broken. If we change from "../deploy-install-guide"  to "/deploy-install-guide" it works!    Mostly occurs with figures/images from one guide to another. Ron will start fixing it.    The links are fine in the upstream STX docs, needs to be fixed for downstreaming.    This will allow WR to use the latest & greatest Sphinx version.  Trailing spaces - we talked about this, the WR team has the action to make the changes using their tool.  Cherry pick process The main thing is to understand the concept of why we would want to do a cherry pick.  All our doc reviews get merged into the master branch, this is our "latest".  Scott has created the branch for Release 5.0, this is our Release 5.0 "snapshot". Here are the 3 main scenarios: 1. Doc reviews that are bug fixes (doc corrections). We will merge into the "latest" by default.  We will manually add the bug fix reviews to the "5.0 snapshot" by doing a cherry pick.  2. Doc reviews that are part of Release 5.0 but still work in progress at the moment. For example, the Doc Release Notes [https://review.opendev.org/c/starlingx/docs/+/777433]   We will merge into the "latest" by default. We will manually add these reviews to the "5.0 snapshot" by doing a cherry pick.  This can happen for a couple of weeks after the release, sometimes there are updates to the installation instructions or release note changes or whatever.  3. Doc reviews that are new features. We will merge them into "latest" by default and will not cherry pick. I think anyone can start the cherry pick process for a review, but it follows the same gatekeeper process as all the other doc reviews. Only the people with the Core role (Bruce, Greg, Ron, and Mary) can approve the cherry pick and start the merge workflow.