Open Stack

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev