Open Stack

+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 <jrist at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Emilien Macchi