Open Stack

On 04/11/2016 06:19 AM, Steven Hardy wrote:
> On Mon, Apr 11, 2016 at 05:54:11AM -0400, John Trowbridge wrote:
>> Hola OOOers,
>>
>> It came up in the meeting last week that we could benefit from a CI
>> subteam with its own meeting, since CI is taking up a lot of the main
>> meeting time.
>>
>> I like this idea, and think we should do something similar for the other
>> informal subteams (tripleoclient, UI), and also add a new subteam for
>> tripleo-quickstart (and maybe one for releases?).
> 
> +1, from the meeting and other recent discussions it sounds like defining
> some sub-teams would be helpful, let's try to enumerate those discussed:
> 
> - tripleo-ci
> - API (Mistral based API which is landing in tripleo-common atm)
> - Tripleo-UI
> - os-net-config
> - python-tripleoclient
> - tripleo-quickstart
> 
> Of these, I think tripleo-ci, tripleo-ui, os-net-config and
> tripleo-quickstart all make sense to create sub-teams.
> 
> However it's less clear if we should create separate teams for
> tripleoclient and the API - IMO everyone should care about the CLI flow, so
> it'd be good to encourage broader participation there, but if there's
> consensus we can add that.
> 
> In the API case it's tough because it's being proposed to tripleo-common,
> so it'll be difficult to have an ACL which only affects the location of the
> API code.  Also it's another key interface where we probably want to really
> encourage broad participation in review/development - currently there's a
> small team working on the API implementation but I really hope that changes
> when we move the Mistral based API to be in the default deployment flow.
> 

For gerrit ACLs, I was thinking the main tripleo-core group would have
core on all of the subteams, and the subteam groups would be just for
adding folks who only have "limited" core responsibilities/privileges.

If we have more strictly limited subteams though, I agree that CLI and
API should probably not be split out.

If we do split out API, I think the ACL being on the whole
tripleo-common repo is fine. There is not a ton of non-API related stuff
in tripleo-common anyways.

> Regarding releases, there actually already is a tripleo-release group, but
> I'm not sure we want to maintain that model long-term, instead we should be
> moving towards the common openstack/releases tooling ref:
> 
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/090737.html
> 
> Improving our release workflow and figuring out how we align/integrate
> better with the OpenStack coordinated/centralized release is high on my
> TODO list as PTL for Newton, and it's definitely something I'm keen to
> discuss further e.g at summit (and get help with! :)
> 
>> We should make seperate ACL's for these subteams as well. The informal
>> approach of adding cores who can +2 anything but are told to only +2
>> what they know doesn't scale very well.
> 
> Agreed, there's definitely value in doing this now and it will provide more
> value as our community grows.
> 
> Steve
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>