Monty Taylor wrote: > However, with a versioned library model, the projects can consume things > pinned to specific versions, and then they can submit a change that > updates the version depend and the code which needs to be updated to > support the version change, and that change can be atomic. > > So honestly, I'd say the real key is getting us closer to the point > where openstack-common is a proper library, because all of the rest of > the complexity is stuff we're inventing to make life harder on > ourselves, when the standard library with api-contract and a version > model of the world works pretty fine without needing coordinated changes > across multiple repositories.
Yes, that's the end goal. And IMHO we are not very far away. I think the main reason we are not there yet is that while a lot of people enjoy giving their opinions about how openstack-common should be done and consumed by projects, not so many people follow up and actually do the work. Making our multiple projects converge onto consolidated and well-accepted APIs is a bit painful work, but it is a prerequisite to turning openstack-common into a proper library (or set of libraries). I'd say the whole thing suffers from not having a proper team/leader/coordinator dedicated to it: relying on existing, overstretched PTLs to lead that effort might not be the fastest path. Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
