Open Stack

On 3 May 2016 at 14:36, Martin André <m.andre at redhat.com> wrote:
> On Tue, May 3, 2016 at 6:48 PM, Michał Jastrzębski <inc007 at gmail.com> wrote:
>> Hello,
>>
>> Since it seems that we have voted for separation of kolla-k8s repos
>> (yay!) I would like to table another discussion (but let's wait till
>> its official).
>>
>> Core Team.
>>
>> We need to build up new core team that will guard the gates on our
>> brand new repo (when it arrives). One of ideas Steven pointed out is
>> to add people from etherpad to core team, but I'd like to throw
>> different idea to the mix, to keep things interesting.
>>
>> Idea is: let's start with current kolla core team and for the time
>> being add new cores to kolla-k8s by invitation by existing core
>> member. For example, I'm kolla core, working with k8s and I see some
>> guy doing great job and investing time into it, I would propose him
>> for core, and instead of normal voting, he will get his +2 powers
>> immediately. This would allow quick core team buildout and not start
>> with bunch of people who doesn't necessary want to contribute or even
>> know each other.
>
> Interesting idea. I wonder if this will favor diversity or on the
> contrary cause cores to nominate their friends.

Yes, that's true. We, kolla core team, need to keep track of it;) I
have confidence in us keeping up diversity.

> Just to put things back in context, we're in this nice situation in
> the kolla project where a couple of companies wrote their own solution
> to run containers with kubernetes and now want to share their work
> with the community. Instead of encouraging a code dump, we'll start a
> new kolla-kubernetes effort from scratch where we can confront ideas
> and incorporate the work from these companies and other contributors.
> We certainly don't want to end up in a situation where a company is
> over-represented, leading to unbalanced discussions, or even worse to
> self-approved patches.
>
> In addition to having cores we trust, I think we can avoid most of
> conflicts by following a simple rule: a company can't push a patch
> through. In other words, we ask core reviewers from different
> affiliations to validate a patch before it can be approved.

+1 to that.

> Martin
>
>> Cheers,
>> Michal
>>
>> __________________________________________________________________________
>> 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
>
> __________________________________________________________________________
> 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