On Tue, May 3, 2016 at 6:48 PM, Michał Jastrzębski <inc...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev