On Tue, 2016-11-01 at 13:17 +0100, Ihar Hrachyshka wrote: > 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.
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: [email protected]?subject:unsubs > cribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
