On Thu, Nov 06 2014, Doug Hellmann wrote: > The main reasons for splitting code into its own library are dependency > management, API ownership, the logical separation of the contents of the > library > within the application stack and between other libraries, and review ACLs > within > gerrit. > > We have a couple of libraries (oslo.log and oslo.messaging) that want to > specify > an API via the context base class, so the class can’t live in either of those > places. > > The utils library is actually used by some of the clients now, so we need to > be > conscious of adding dependencies there. I don’t think context will bring in > any > real dependencies for now, but it also doesn’t seem to be a general-purpose > utility. We’re going to need to add some thread-local caches for setting and > fetching the current context, I think, either within context or in some of the > other libraries with callbacks invoked by the context constructor. So for > logical separation, a different library seemed to make more sense. > > It’s also possible that the applications will find other uses for a shared > context base class, and so we’ll want to build a review team for it that isn’t > limited to the oslo-core team, but that’s less important than the logical > considerations in my mind.
Ok, I can agree with all of that. I'm just not sure the burden of having yet another lib/repo/team is worth it for this lib. But you seem pretty confident about it and I don't have any massive objection. (And anyway I'll still have this mailing list thread to refer in a few months for an I-told-you-so just in case. :-) So that repo LGTM dims. -- Julien Danjou ;; Free Software hacker ;; http://julien.danjou.info
signature.asc
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev