> On Jan 28, 2016, at 4:04 PM, Joshua Harlow <harlo...@fastmail.com> wrote: > > Ryan Rossiter wrote: >> >> As the-guy-in-nova-that-does-this-a-bunch, I’ve pushed a bunch of changes to >> nova because we didn’t have them yet in o.vo, and once they get released, I >> “re-sync” them back to nova to use the o.vo version, see: >> >> https://review.openstack.org/#/c/272641/ >> https://github.com/openstack/oslo.versionedobjects/commit/442ddcaeab0184268ff987d4ff1bf0f95dd87f2e >> https://github.com/openstack/oslo.versionedobjects/commit/b8818720862490c31a412e6cf6abf1962fd7a2b0 >> https://github.com/openstack/oslo.versionedobjects/commit/cb898f382e9a22dc9dcbc2de753d37b1b107176d >> >> I don’t find it all that terrible, but maybe that’s because I’m only >> watching it in one project. > > Just out of curiosity but is this due to o.vo not merging reviews fast > enough? Not releasing fast enough? A desire to experiment/prove out the > additions in nova before moving to o.vo? Or something else?
Even though I am an impatient person, it’s not because of #1 or #2. Part of it is to prove it works in nova. But I think the main reasoning behind most of them are because nova already has most of the duplicated code, and in order to let us use o.vo, there needs to be a slight change to it. So my steps in committing to both are 1) fix it in nova’s duplicated code, 2) fix it in o.vo 3) get the change merged/released in o.vo 4) eliminate all duped code from nova, cut over completely to o.vo. So the main reasons are forks and to answer the question “why does o.vo need this?”. The change this thread discusses doesn’t fall under this realm, we know why we need/want it. But my situations are just a data point to add towards carrying it in both places isn’t the end of the world (though I’m not saying this approach is the best way to do it). > > From my point of view it feels odd to have a upstream (o.vo) and a downstream > (nova) where the downstream in a way carries 'patches' on-top of o.vo when > both o.vo and nova are in the same ecosystem (openstack). I would totally agree, if o.vo was purely upstream of nova. Unfortunately, nova is still carrying a lot of leftovers, and because of the “forks” I need to push something to both of them so I can bring them together in the future. I’m doing my best at bringing these two closer together. > >> ----- >> Thanks, >> >> Ryan Rossiter (rlrossit) >> >> >> __________________________________________________________________________ >> 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 ----- Thanks, Ryan Rossiter (rlrossit) __________________________________________________________________________ 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
