[openstack-dev] [kolla][kolla-k8s] Core team

Martin André m.andre at redhat.com
Tue May 3 19:36:48 UTC 2016


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.

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.

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



More information about the OpenStack-dev mailing list