Agenda and notes for the 8/16 call:
o
The current draft is good and acceptable to the Core team. We suggest appointing four members to the Initial TSC - Dean, Saul, Brent and Ian. We have an open issue in regard to how/when/if the TSC should grow in the Bootstrapping
phase. We are looking for guidance from the Foundation in how to handle this.
·
Centos 7.5 upgrade status and plan
o
Ada's test content is minimal at this point. Will take time to ramp that up.
o
Brent can talk to the WR test lead to see if cycles can be run there
o
Do we pull a branch for this? Only Brian (sniff) and Dean have the ability to create branches right now. Dean to ramp Scott and Saul to that list.
o
Issues with branching (in general)
o
Dean to start a thread on the mailing list to continue the discussion there. Given the above he thinks a feature branch is an easier sell.
o
Bruce met with Intel folks working on the project. Possible ways for StarlingX to be part of their overall architecture, in what they call the "System Management" layer. Needs deeper technical / architectural analysis.
o
We need to be aware of this project and figure out our plan of engagement.
o
Intel is looking to enable support for Clear Linux. Supporting Ubuntu would have more impact in the community. Key work items would be supporting multiple package managers and (somehow) keeping the KPIs intact.
o
We (Brent, Ian, Saul, Dean) need to prep for a deep discussion on this topic at the PTG.
o
Saul is working on a way to abstract out the configuration patches into some other mechanism.
o
Need to review / design a way to handle multiple installers, how to build the abstraction layers needed in Update, etc...
o
Containerizing more content in Docker images can help with middleware layers, but they still need an OS image to run against. It may also cause us other issues e.g. how do we update all of the containers when the OS changes.
o
Ian will facilitate a call to start this effort.
o
How do we scale specs from small micro-feature (1-2 commits) to major features with multiple commits over a long time?
o
How to we store, review, process, approve specs?
o
We should require some level of spec for any feature that introduces new patches
o
Keep it lightweight, low friction. Provide guidelines to make this easy.
o
Using a repo for specs allows the discussion to be captured there. Using LP isn't a great way to have a discussion. Dean doesn't recommend using LP Blueprints. Team agrees that we should establish a stx-specs repo. Saul to
create the repo with Dean's guidance.
o
Further discussions on the spec process deferred to next time