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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ 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