Armando M. <[email protected]> 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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
