<br><br><div class="gmail_quote">On Fri, Aug 3, 2012 at 1:35 PM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<br>
On 08/03/2012 12:32 PM, Doug Hellmann wrote:<br>
><br>
><br>
> On Fri, Aug 3, 2012 at 11:24 AM, Mark McLoughlin <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a><br>
</div><div><div class="h5">> <mailto:<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>>> wrote:<br>
><br>
>     On Fri, 2012-08-03 at 10:16 -0500, Monty Taylor wrote:<br>
>     > On 08/03/2012 09:57 AM, Kevin L. Mitchell wrote:<br>
>     > > On Fri, 2012-08-03 at 17:48 +0300, Gary Kotton wrote:<br>
>     > >> Will you also be fixing the pep8 issues in the common code?<br>
>     > ><br>
>     > > When the pep8 running in openstack-common reports the issue, yes, it<br>
>     > > will make sense to fix it.  Since I have already synchronized<br>
>     nova and<br>
>     > > glance, I'm highly reluctant to make the necessary change.  I'll<br>
>     also<br>
>     > > point out that the particular condition that pep8 is reporting<br>
>     here is<br>
>     > > all over the place in nova and probably also in glance…<br>
>     ><br>
>     > If we keep openstack-common testing against latest pep8 (even when<br>
>     it's<br>
>     > a pita) it should allow us to drop that code into any of the projects<br>
>     > without worrying about which version they've caught up to.<br>
><br>
>     Yeah, I'm fine with us using latest pep8.<br>
><br>
>     > Also - I hear that one of these days we're going to make a library out<br>
>     > of openstack common ... how's that coming Mark?<br>
><br>
>     There are two parts - figuring out which APIs are ready for the<br>
>     backwards compat commitment and sorting out the pure mechanics of doing<br>
>     the library release.<br>
><br>
>     I was mostly blocked on the first part and this week took a look at the<br>
>     RPC API to see if it's ready:<br>
><br>
>       <a href="https://blueprints.launchpad.net/openstack-common/+spec/rpc-api-review" target="_blank">https://blueprints.launchpad.net/openstack-common/+spec/rpc-api-review</a><br>
><br>
>     The summary from a first review is that it's not too far away, but does<br>
>     need more work. Just doing a thorough review is pretty time consuming,<br>
>     though, nevermind fixing the issues themselves.<br>
><br>
>     Talking it over with Russell, we thought it might make sense to tackle<br>
>     the second part of the problem first - if e.g. we're happy with the<br>
>     state of cfg, we could do an initial library release with just that and<br>
>     be happy we have the mechanics sorted out. Then we can iterate through<br>
>     reviews of the other APIs and add them to future releases.<br>
><br>
><br>
> Are we still planning to have a single monolithic library? I would<br>
> really like for us to consider releasing smaller reusable chunks that<br>
> might be usable/useful in projects other than OpenStack.<br>
<br>
</div></div>I'm fine with supporting either, depending on how interdependent they<br>
are. Main thing is one library == one repo. As long as we stick to that,<br>
it should be a piece of cake. If we want these to be things like<br>
"openstack-common-config" which provides openstack.common.config, then<br>
we'll probably want to hit-it with some namespace packages.<br></blockquote><div><br></div><div>I was thinking a single namespace package "openstack" with single-level nested packages such as openstack.config, openstack.messaging (to include rpc and notifications), openstack.server (service and manager-related stuff, maybe also the wsgi stuff). The "common" feels a little redundant.</div>
<div><br></div><div>OTOH, it would be even better if we came up with names that didn't include "openstack" in the distro or package name. That would help avoid the Zope-branding issue that keeps other projects from adopting a lot of the useful components that came out of the Zope project just because they are apparently tied to Zope. Of course, naming is one of the hard problems in compsci. :-)</div>
<div><br></div><div>Doug</div><div><br></div></div>