[all] [tc] [osc] [glance] [train] [ptls] Legacy client CLI to OSC review 639376
>> reliance on a central (OSC) team for implementation and reviews.
<snip>>> Would moving tools like cinder or glance to OSC plugins help solve
> upside is project teams could move things themselves faster, like they
> do with their own python-*client projects today. They are also the ones
> that know better how their API works.
> The downside of project teams owning their parts of the CLI are losing a
> unified vision
> we would have to trust them
> I would still want Dean
> overseeing things happening at the component level though, at least
> until there are more obvious OSC-wide cores, i.e. component core(s)
> +1/+2 a thing but Dean has final say.
This is becoming a familiar theme for projects/efforts with touchpoints
Docs deliverables have been moved into individual projects, and "the
docs team" is becoming a SIG . But who is the Dean of docs, making
sure we retain a common structure, style, and voice across all of these
SDK is making forays into the "trust component SMEs" arena .
The API-SIG is undergoing a similar existential exercise , and it is
unclear where its deliverables will end up.
And this issue with OSC is not new.
All of these have their own nuances, but also quite a bit in common. Can
we brainstorm ways that might address more than one in a satisfactory
way? Here's one idea:
Deliverables live in projects under the governance of their component;
so for example nova-docs and nova-osc-plugin and nova-sdk-plugin would
be under nova governance, with core teams managed by nova. But patches
in those projects require an additional vote of a different flavor (a
"Rollcall-Vote"?) from the related SIG or core team in order to merge.