On Mon, Sep 23, 2013 at 9:56 PM, Adam Young <[email protected]> wrote:
> On 09/23/2013 03:21 PM, Doug Hellmann wrote: > > > > > On Mon, Sep 23, 2013 at 4:25 AM, Flavio Percoco <[email protected]> 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. > 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? Doug > > > > > > 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 >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > _______________________________________________ > OpenStack-dev mailing > [email protected]http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
