On 3 May 2016 at 14:36, Martin André <m.an...@redhat.com> wrote: > 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.
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-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 __________________________________________________________________________ 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