Agenda and Notes for the Oct 24th call * Let's do a release!!! o Our new web page is live! o Bug status ? Only one stx.2018.10 bug still open: https://bugs.launchpad.net/starlingx/+bug/1797234 * Notes say that the issue is not reproducible, so this does not hold up stx.2018.10 - removing the label and recommending closure ? A quick review of the new bugs in the last couple of days does not reveal in any issues that would hold up the release ? Erich to file a new launchpad for the latest build issues on master - potential build blocking issues in the mirror script * RT kernel package location - to be discussed over email... * https://review.openstack.org/#/c/612822/ o Testing status o Docs status ? Release note status o Backporting policy??? ? Changes that are candidates for backporting should be sent to the [Release] team in email. ? Release team will review and decide if a backport is required. o Release tagging is on hold until EOD today, with a strong desire to get the build changes in first. * Priorities for r/2019.03 o See https://etherpad.openstack.org/p/stx-2019.03-priorities o Strongly encourage sub-projects TL/PLs to put together their lists/plans and update the etherpad asap. * When to post code for review? Early and often? After testing? o https://wiki.openstack.org/wiki/StarlingX/CodeSubmissionGuidelines o We should consider clarifying the early review needed to catch design issues between the final code inspection that gates code acceptance o The Intel team in particular would benefit from early/often review o The goal is to help close the gap on detailed design approaches where the spec may not cover that level of detail, but the developer needs input on the approach before being able to test. o There are mechanisms that the developer should use to make it clear that they are requesting early feedback by including WIP or RFC in the first line of the commit message and/or Workflow -1 by the review submitter o Core reviewer workload is high but we can offload that to Contributors who are all able to review code. * How to test complex changes? o Leverage the virutal environment where possible e.g. in the current Ceph changes that need testing can be done in a virtual duplex config o Other changes that require real hardware should be discussed with the Test team. * Thank you to everyone for all your work on the release! * The new website is live! * @StarlingX on twitter is live, please re-tweet. * Please join the webinar at 8AM PT today.