Open Stack

On 09/23/2013 03:21 PM, Doug Hellmann wrote:
>
>
>
> On Mon, Sep 23, 2013 at 4:25 AM, Flavio Percoco <flavio at redhat.com 
> <mailto:flavio at redhat.com>> wrote:
>
>     On 20/09/13 15:20 -0700, Monty Taylor wrote:
>
>         On 09/20/2013 02:55 PM, Ben Nemec wrote:
>
>             Not from a Gerrit perspective, but the Oslo policy is that
>             a maintainer
>             +1 on the code they maintain is the equivalent of a +2, so
>             only one core
>             is needed to approve.
>
>             See
>             https://github.com/openstack/oslo-incubator/blob/master/MAINTAINERS#L28
>
>
>         What if we rethought the organization just a little bit.
>         Instead of
>         having oslo-incubator from which we copy code, and then oslo.*
>         that we
>         consume as libraries, what if:
>
>         - we split all oslo modules into their own repos from the start
>
>
>     IIRC, we're planning to have a design session around these lines at
>     the summit. I think the only issue here is figuring out where some
>     modules belong. For example, where would we put strutils? Should we
>     have a single repo for it or perhaps have a more generic one, say
>     oslo.text, were we could group strutils, jsonutils and some other
>     modules?
>
>     There are plenty of "single-file" packages out there but I'd
>     personally prefer grouping modules as much as possible.
>
>
> I agree.
>
>
>     Another thing to consider is, what happens with Oslo modules depending
>     on other oslo modules? I guess we would make sure all the dependencies
>     are copied in the project as we do today but, when it comes to testing
>     the single module, I think this could be an issue. For example,
>     policy.py depends on fileutils, gettextutils and other oslo module
>     which wouldn't fit in the same package, oslo.policy. This will make
>     testing oslo.policy a real pain since we would have to "copy" its
>     dependencies in its own tree as well.
>
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> How close is the policy code to being ready to graduate?

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.



>
> Doug
>
>
>
>         - we make update.py a utility that groks copying from a
>         directory that
>         contains a bunch of repos - so that a person wanting to use is
>         might have:
>          ~/src
>          ~/src/oslo
>          ~/src/oslo/oslo.db
>          ~/src/oslo/oslo.policy
>          and then when they run update.py ~/src/oslo ~/src/nova and
>         get the
>         same results (the copying and name changing and whatnot)
>
>
>     If we split modules in its own repos, I'd rather use git submodules,
>     which would then work better. 
>
>
>
>
>         That way, we can add per-module additional core easily like we
>         can for
>         released oslo modules (like hacking and pbr have now)
>
>
>     +1
>
>
>
>         Also, that would mean that moving from copying to releasing is
>         more a
>         matter of just making a release than it is of doing the git
>         magic to
>         split the repo out into a separate one and then adding the new
>         repo to
>         gerrit.
>
>
>     +1
>
>         Thoughts?
>
>
>     I like the idea overall, I'm a bit worried about how those modules
>     would be organized.
>
>     Any thoughts about the above concerns?
>
>
>     Cheers,
>     FF
>
>     -- 
>     @flaper87
>     Flavio Percoco
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130923/e6f9e7c8/attachment.html>