[openstack-dev] Client and Policy

Monty Taylor mordred at inaugust.com
Fri Sep 20 22:20:09 UTC 2013



On 09/20/2013 02:55 PM, Ben Nemec wrote:
> On 2013-09-20 03:16, Flavio Percoco wrote:
>> On 19/09/13 17:10 -0400, Adam Young wrote:
>>> On 09/19/2013 04:30 PM, Mark McLoughlin wrote:
>>>> To take the specific example of the policy API, if someone actively
>>>> wanted to help the process of moving it into a standalone library
>>>> should
>>>> volunteer to help Flavio out as a maintainer:
>>>>
>>>>    
>>>>  
>>>>  
>>>> ps://git.openstack.org/cgit/openstack/oslo-incubator/tree/MAINTAINERS
>>>>
>>>>   == policy ==
>>>>
>>>>   M: Flavio Percoco <flavio at redhat.com>
>>>>   S: Maintained
>>>>   F: policy.py
>>>
>>> Would it make sense to explicitly add Keystone developers, or can we
>>> include the launchpad keystone-core group to this module?
>>> If we want to keep it per user,  I'm willing to do so, and I think we
>>> have a couple of other likely candidates from Keystone:  I'll let
>>> then speak up for themselves.
>>>
>> I don't think it is possible to have per-file core reviewers.
> 
> 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
- 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)

That way, we can add per-module additional core easily like we can for
released oslo modules (like hacking and pbr have now)

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.

Thoughts?



More information about the OpenStack-dev mailing list