Open Stack

On Tue, 2016-11-01 at 13:17 +0100, Ihar Hrachyshka wrote:
> Armando M. <armamig at gmail.com> wrote:
> > 
> > Slight variation, call it option 6:
> > 
> > 1) Identify the most impacted (coupled) project affected by these
> > changes.
> > 2) Fix it in order to provide folks with a recipe for how to
> > address the  
> > breakages.
> 
> ^ the step depends on how far we want to go with the adoption. If
> it’s just  
> changing import paths, then it will be easy but will give wrong
> signal to  
> subprojects that the whole practice of them piggy-backing on
> neutron  
> options is acceptable. On the other hand, we could help them get off
> the  
> hook, by working in scope of neutron-lib to expose whatever they
> *really*  
> need (and switch off neutron options completely where there is no
> clear  
> semantic requirement for the option value to be shared).
> 
> While the latter path is not as easy, I would prefer it any time. It
> is in  
> line with the neutron-lib effort goal to decouple stadium subprojects
> from  
> neutron code base.

Yeah this is pretty much the real question of this thread.  How much
impact to subprojects is acceptable in getting to the 100% decoupled
state?

> 
> > 3) Use the patch and make it needed-by the neutron changes.
> > 4) Evangelize patch 2 one more time on the ML.
> > 5) We'll bring this up at the team meeting, for another form or
> > record.
> > 6) Wait another few days for projects to catch up.
> > 7) Merge the patch in neutron.
> > 8) We all move on.
> 
> _____________________________________________________________________
> _____
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev