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.
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.
- 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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
