<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 23, 2013 at 9:56 PM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div><div class="h5">
<div>On 09/23/2013 03:21 PM, Doug Hellmann
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Mon, Sep 23, 2013 at 4:25 AM,
Flavio Percoco <span dir="ltr"><<a href="mailto:flavio@redhat.com" target="_blank">flavio@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>On 20/09/13 15:20 -0700, Monty Taylor
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
On 09/20/2013 02:55 PM, Ben Nemec wrote:<br>
</div>
<div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Not
from a Gerrit perspective, but the Oslo policy is
that a maintainer<br>
+1 on the code they maintain is the equivalent of a
+2, so only one core<br>
is needed to approve.<br>
<br>
See <a href="https://github.com/openstack/oslo-incubator/blob/master/MAINTAINERS#L28" target="_blank">https://github.com/openstack/oslo-incubator/blob/master/MAINTAINERS#L28</a><br>
</blockquote>
<br>
What if we rethought the organization just a little
bit. Instead of<br>
having oslo-incubator from which we copy code, and
then oslo.* that we<br>
consume as libraries, what if:<br>
<br>
- we split all oslo modules into their own repos from
the start<br>
</div>
</blockquote>
<br>
IIRC, we're planning to have a design session around these
lines at<br>
the summit. I think the only issue here is figuring out
where some<br>
modules belong. For example, where would we put strutils?
Should we<br>
have a single repo for it or perhaps have a more generic
one, say<br>
oslo.text, were we could group strutils, jsonutils and
some other<br>
modules?<br>
<br>
There are plenty of "single-file" packages out there but
I'd<br>
personally prefer grouping modules as much as possible.<br>
</blockquote>
<div><br>
</div>
<div>I agree.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Another thing to consider is, what happens with Oslo
modules depending<br>
on other oslo modules? I guess we would make sure all the
dependencies<br>
are copied in the project as we do today but, when it
comes to testing<br>
the single module, I think this could be an issue. For
example,<br>
policy.py depends on fileutils, gettextutils and other
oslo module<br>
which wouldn't fit in the same package, oslo.policy. This
will make<br>
testing oslo.policy a real pain since we would have to
"copy" its<br>
dependencies in its own tree as well.</blockquote>
<div><br>
</div>
<div>This is a great reason to keep everything together in a
single incubator repository until a package is ready to
stand on its own as a library. Libraries can easily
declare dependencies to be installed for testing, but if
we start copying bits of oslo around into separate git
repositories then we'll all go mad trying to keep all of
the repos up to date. :-) In the mean time, any review
pain we have can be used as encouragement to bring the
library to a point where it can be moved out of the
incubator.</div>
<div><br>
</div>
<div>It sounds like the primary concern is having enough
keystone folks looking at reviews of the policy code,
without being overwhelmed by tracking all Oslo changes.
There are a couple of ways to address that.</div>
<div><br>
</div>
<div>
<div>The policy code seems very tightly associated with
the keystone work. There's no reason for Oslo to be the
only program releasing reusable libraries. We should
consider having the Keystone team manage the policy
library in a repo they own. I'd love to have the
Keystone middleware work the same way, instead of being
in the client repo, but one step at a time.</div>
</div>
<div><br>
</div>
<div>
<div>Of course, if the policy code is nearing the point
where it is ready to graduate from the incubator, then
maybe that suggestion is moot and we should just
continue to push ahead on the path we're on now. We
could have people submitting policy code to
oslo-incubator add "keystone-core" to reviews (adding a
group automatically adds its members), so they don't
have to subscribe to oslo notifications.</div>
<div><br>
</div>
<div>How close is the policy code to being ready to
graduate?</div>
</div>
</div>
</div>
</div>
</blockquote>
<br></div></div>
I would argue that it should graduate now. Keystone is willing to
take it on as a subproject, just like the keystoneclient code is.
We discussed putting it in keystoneclient, since auth_token
middleware is there already. Thus, anything already using
auth_token middleware already has the package.</div></blockquote><div><br></div><div>I like that in general, although I'd rather see it in a separate repository than piled into the client -- unless there's a connection between the policy code and the client code that I just don't understand?</div>
<div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div><div class="h5"><br>
<br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Doug</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">-
we make update.py a utility that groks copying from a
directory that<br>
contains a bunch of repos - so that a person wanting
to use is might have:<br>
~/src<br>
~/src/oslo<br>
~/src/oslo/oslo.db<br>
~/src/oslo/oslo.policy<br>
and then when they run update.py ~/src/oslo
~/src/nova and get the<br>
same results (the copying and name changing and
whatnot)<br>
</blockquote>
<br>
</div>
If we split modules in its own repos, I'd rather use git
submodules,<br>
which would then work better. </blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
That way, we can add per-module additional core easily
like we can for<br>
released oslo modules (like hacking and pbr have now)<br>
</blockquote>
<br>
</div>
+1
<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Also, that would mean that moving from copying to
releasing is more a<br>
matter of just making a release than it is of doing
the git magic to<br>
split the repo out into a separate one and then adding
the new repo to<br>
gerrit.<br>
<br>
</blockquote>
<br>
</div>
+1<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Thoughts?<br>
</blockquote>
<br>
I like the idea overall, I'm a bit worried about how those
modules<br>
would be organized.<br>
<br>
Any thoughts about the above concerns?
<div><br>
<br>
Cheers,<br>
FF<br>
<br>
-- <br>
@flaper87<br>
Flavio Percoco<br>
<br>
</div>
<div>
<div>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>