Dan Smith wrote:
3. vish brought up one draw back of versioned objects: the difficulty in
cherry picking commits for stable branches - Is this a show stopper?.
After some discussion with some of the interested parties, we're
planning to add a third .z element to the version numbers and use that
to handle backports in the same way that we do for RPC:
https://review.openstack.org/#/c/134623/
Next steps:
- Jay suggested making a second spec that would lay out what it would
look like if we used google protocol buffers.
- Dan: do you need some help in making this happen, do we need some
volunteers?
I'm not planning to look into this, especially since we discussed it a
couple years ago when deciding to do what we're currently doing. If
someone else does, creates a thing that is demonstrably more useful than
what we have, and provides a migration plan, then cool. Otherwise, I'm
not really planning to stop what I'm doing at the moment.
- Are there any other concrete things we can do to get this usable by
other projects in a timely manner?
To be honest, since the summit, I've not done anything with the current
oslo spec, given the potential for doing something different that was
raised. I know that cinder folks (at least) are planning to start
copying code into their tree to get moving.
I think we need a decision to either (a) dump what we've got into the
proposed library (or incubator) and plan to move forward incrementally
or (b) each continue doing our own thing(s) in our own trees while we
wait for someone to create something based on GPB that does what we want.
I'd prefer (a); although I hope there is a owner/lead for this library
(dan?) and it's not just dumped on the oslo folks as that won't work out
so well I think. It'd be nice if said owner could also look into (b) but
that's at there own (or other library supporter) time I suppose (I
personally think (b) would probably allow for a larger community of
folks to get involved in this library, would potentially reduce the
amount of custom/overlapping code and other similar benefits...).
--Dan
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
