Open Stack

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