Open Stack

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.

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