+1 from me too, we have it in Puppet OpenStack group, and it works just fine.
On Mon, Apr 11, 2016 at 10:27 AM, Jason Rist <jr...@redhat.com> wrote: > On 04/11/2016 04: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. >> >> 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 >> > Very big +1 to this. I feel like it will help speed up the dev process. > > -- > Jason E. Rist > Senior Software Engineer > OpenStack User Interfaces > Red Hat, Inc. > openuc: +1.972.707.6408 > mobile: +1.720.256.3933 > Freenode: jrist > github/twitter: knowncitizen > > __________________________________________________________________________ > 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 -- Emilien Macchi __________________________________________________________________________ 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
