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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev