On 09/23/2013 03:21 PM, Doug Hellmann wrote:
On Mon, Sep 23, 2013 at 4:25 AM, Flavio Percoco <[email protected]
<mailto:[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.
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]
<mailto:[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
