If the project plugins were maintained by the OSC project still, maybe there would be incentive for the various other projects to join the OSC project, scaling things up?
Thanks, Kevin ________________________________________ From: Matt Riedemann [mriede...@gmail.com] Sent: Thursday, September 27, 2018 12:12 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Openstack-sigs] [goals][tc][ptl][uc] starting goal selection for T series On 9/27/2018 10:13 AM, Dean Troyer wrote: > On Thu, Sep 27, 2018 at 9:10 AM, Doug Hellmann<d...@doughellmann.com> wrote: >> Monty Taylor<mord...@inaugust.com> writes: >>> Main difference is making sure these new deconstructed plugin teams >>> understand the client support lifecycle - which is that we don't drop >>> support for old versions of services in OSC (or SDK). It's a shift from >>> the support lifecycle and POV of python-*client, but it's important and >>> we just need to all be on the same page. >> That sounds like a reason to keep the governance of the libraries under >> the client tool project. > Hmmm... I think that may address a big chunk of my reservations about > being able to maintain consistency and user experience in a fully > split-OSC world. > > dt My biggest worry with splitting everything out into plugins with new core teams, even with python-openstackclient-core as a superset, is that those core teams will all start approving things that don't fit with the overall guidelines of how OSC commands should be written. I've had to go to the "Dean well" several times when reviewing osc-placement commands. But the python-openstackclient-core team probably isn't going to scale to fit the need of all of these gaps that need closing from the various teams, either. So how does that get fixed? I've told Dean and Steve before that if they want me to review / ack something compute-specific in OSC that they can call on me, like a liaison. Maybe that's all we need to start? Because I've definitely disagreed with compute CLI changes in OSC that have a +2 from the core team because of a lack of understanding from both the contributor and the reviewers about what the compute API actually does, or how a microversion behaves. Or maybe we just do some kind of subteam thing where OSC core doesn't look at a change until the subteam has +1ed it. We have a similar concept in nova with virt driver subteams. -- Thanks, Matt __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev