Thanks for everyone who attended the release kick-off meeting today. Minutes are kept at: https://etherpad.openstack.org/p/stx-releases I strongly recommend that all Team Leads review the minutes and respond with any questions/concerns. Please note that we will forgo weekly meetings on Tuesday for now and will add release topics as an item on the Wednesday community meeting. Ad hoc meetings will be called as needed. Code Freeze Count-Down: 3wks Minutes: * Align on release deliverables ? We have something related to this documented on the wiki already: https://wiki.openstack.org/wiki/StarlingX/Release_Plan#Release_Definition * Team validated the assumption that STX is a source-only project, so the above release definition is still accurate * Content ? What to do with target content that doesn't make it at the code freeze date? * STX releases are time-based. Content that doesn't make it is moved to the next release by default (or abandoned). * Features: Move to the next release (i.e. re-tag) o No feature content after the code freeze date * Bugs: Ideally we want current gating bugs to have been addressed by the code freeze, but can consider deferring some to the RC period. * Mechanics for creating the release branch/tags ? Do we want an RC period? If so, how do we want to handle it? * Reference: For Openstack, code freeze happens first; this is a hard date where master is frozen for a period. Then they enter the RC period: each project creates their branch and tags it as RC1. After some stability period,eachproject re-tags until the relase date. OpenStack RCs are actually re-tagged for the release if there are no changes at release time. * For StarlingX, we agreed on code freeze (hard date: Sept 26), then have a review to decide when to create the branch (may want to wait for a few items that are close). This approach gives us the flexibility. o After code freeze, master is frozen until the release branch is created. o The release branch will be created for all repo's at the same time. o The release branch will be called: r/2018.10 and will initially be tagged as 2018.10.0 (RC1). ? Re-tagging frequency TBD * Release Branch Creation Criteria: o Build Successful o Sanity Passed o Release stake-holders review and agree to create release branch * Test activities/plan once release branch is created ? Daily automated sanity will continue on master as well as the release branch ? Test team is working on defining test-cases to be run on the release branch. Target is 300 TCs to be run manually. ? AR: Ada to share list of TCs with the team once available. Target: Sept19 ? All configuration will be covered: multi-node w/ storage, multi-node w/o storage, simplex, duplex ? Testing will cover baremetal as well as the virtual environment * Bug Management during the RC period ? Use Bug template ? Always source in master first ? Criteria for which bugs gate the release and require a cherry-pick to the release branch. Who is responsible for cherry-picking? * Ghada will continue to tag bugs with the appropriate sub-project tag to make the bugs visible to the appropriate sub-team - pinging TLs as needed. * Ghada will also add the Launchpad query (Bugs Needing Triage) to the wiki to make it more accessible to all sub-teams. * Each sub-team will decide whether a reported bug gates the release as they are in the best position to articulate the impact. If gating, the bug must be tagged with stx.2018.10 * Each designer is responsible for cherry picking the fix from the master branch to the release branch. Only bugs tagged with stx.2018.10 should be cherry-picked. * AR: Team Leads should be able to assign bugs to their team members. Ghada to figure out if team membership is the requirement to be able to do this * Documentation ? Content to include: * Release Notes o Agreed to generate high level release notes only o Doc team is automating the generation of the release notes. Infrastructure should be ready by next week. o Automated release notes are created per repo. ? stx-metal is currently used as the first repo to generate release notes as well as general documentation and api-reference guides ? Each sub-team will create high level release note place-holders and populate them once the process is proven and published. ? api-ref documentation will be handled by the documentation team o High level list of features ? Each sub-team to decide whether to list some key features or at least an introduction to the sub-project (main functionality, etc) o Limitations/Caveats ? No plan to document a list of fixed/open bugs for this release ? Each sub-team can decide what limitations/caveats they want to document in their per-repo o If we want overall StarlingX release notes, these need to be hand crafted. ? TBD whether we will do this o Review Release Notes Management email: http://lists.starlingx.io/pipermail/starlingx-discuss/2018-August/000690.htm... o Release Notes Tracking ? https://wiki.openstack.org/wiki/StarlingX/Releases/Release_Notes * Standard Documentation - Developer Guide / API / others o Documentation Tracking ? https://wiki.openstack.org/wiki/StarlingX/Documentation o API Reference Tracking ? https://wiki.openstack.org/wiki/StarlingX/Developer_Guide/API_Documentation o Doc team has this under control; no specific items discussed ? Format * I believe the doc team have a plan for this already o See above Tracking links for Documentation, Release Notes and API Reference o See notes above * Weekly Calls ? Get agreement on weekly calls -- Proposal: Tuesday 9am Eastern / several options for afternoon slots if China not attending (Tuesday 5pm / Thursday 1pm or 3pm) ? Agreed to cover the release topics in the Wednesday community meeting. If there are major issues, then we can book an ad-hoc meeting as required Regards, Ghada