On 8/23/19 5:47 PM, Eric Fried wrote:
reliance on a central (OSC) team for implementation and reviews. <snip>>> Would moving tools like cinder or glance to OSC plugins help solve <snip> 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. <snip> The downside of project teams owning their parts of the CLI are losing a unified vision <snip> we would have to trust them <snip> 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 across OpenStack.
Docs deliverables have been moved into individual projects, and "the docs team" is becoming a SIG [1]. But who is the Dean of docs, making sure we retain a common structure, style, and voice across all of these deliverables?
SDK is making forays into the "trust component SMEs" arena [2].
The API-SIG is undergoing a similar existential exercise [3], 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.
I don't dislike the idea, but I think the decentralization of these things is at least partially a recognition of the fact that the teams have shrunk to the point where they can't be responsible for reviewing every doc/sdk/cli change across all of openstack (if they ever could in the first place). It may be that the best we can do is have the remaining experts in those areas write up guidelines[0] for the project contributors to follow and then pull the experts in to review specific edge cases and such. The bad thing is that mistakes in stuff like the cli and sdk can be hard to fix once they've been released. I can't tell you how many bugs I ran into because scripts were using the old glance image visibility cli opt that got changed way back when. But that might just be something we have to live with unless I'm wrong about the review capacity of the teams in question. 0: Something like https://docs.openstack.org/python-openstackclient/stein/contributor/humanint... but maybe even more than that since I think I've seen Dean mention best practices that aren't covered in that doc.
Thoughts?
efried
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-August/thread.ht... [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-August/thread.ht... [3] http://lists.openstack.org/pipermail/openstack-discuss/2019-August/thread.ht...