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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to