Open Stack

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.

> 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.