[openstack-dev] [kolla][kolla-k8s] Core team
inc007 at gmail.com
Tue May 3 20:57:23 UTC 2016
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:
>> 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.
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev