<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 class="im">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 class="im">
On 09/20/2013 02:55 PM, Ben Nemec wrote:<br>
</div><div class="im"><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/<u></u>oslo-incubator/blob/master/<u></u>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><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 class="im"><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 class="im">
<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 class="im"><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 class="im"><br>
<br>
Cheers,<br>
FF<br>
<br>
-- <br>
@flaper87<br>
Flavio Percoco<br>
<br></div><div class=""><div class="h5">
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>