So I agree with you that we need policy established here. What I'm getting at - which core teams will vote on inclusion of new deliverable? All of them? Just Kolla? This is grey area I'm referring to. What's kolla-k8s core team's business if somebody would like to add saltstack support? What I wouldn't want to have is to establish new semi-tc in form of our core team that will decide what is and isn't good orchiestration engine for Kolla. That would seriously hinder our ability to innovate, experiment. What if we find out this new orchiestration engine and just want to play with it? But keep it community from start?
So let me throw an idea there, one which we should vote on: Prep: 1. We create kolla-policy-core-team which is sum of all core teams of kolla supported projects 2. We create list of kolla supported projects - today it's kolla, kolla-ansible and kolla-k8s Add new project: 1. Everyone is free to create kolla-* deliverable as long as they follow certain documented standards (action: document these) 2. We create lightweight process to include new deliverable to Kolla, like just 2* +2 from kolla-policy-core-team to include project like that 3. If project gets traction, interest and is successful, we vote on including it's core team to kolla-policy-core-team This way it would be easy to try and fail fast to run kolla with whatever. We need this kind of flexibility for people to innovate. Thoughts? Michal On 23 December 2016 at 13:11, Steven Dake (stdake) <[email protected]> wrote: > Michal, > > Really what I was getting at was placing in the governance repository as a > kolla deliverable. In days past we *always* voted on additions and removals > of deliverables. It doesn’t seem like a gray area to me – we have always > followed a voting pattern for adding and removal of deliverables. This repo > could be added to the git openstack namespace but then not have it as a kolla > deliverable without a vote I think; this is sort of what Fuel did with > Fuel-ccp – that proposal is a gray area. I found when Fuel did that to be > extremely odd personally ☺ I’m not sure if there is a trademark policy or > something similar that affects the use of Kolla and OpenStack together. I’ve > included the [tc] in the topic so they can provide guidance on the route you > suggested (incubation for new kolla deliverables that are not actually > deliverables). > > I think we really don’t need the tc to intervene here though, we can just > make new policies on our own via the typical policy voting process we have > followed in the past. Before we make any decisions about that though, I > think we need a vote on the topic. ☺ > > Regards > -steve > > -----Original Message----- > From: Michał Jastrzębski <[email protected]> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > <[email protected]> > Date: Friday, December 23, 2016 at 10:08 AM > To: "OpenStack Development Mailing List (not for usage questions)" > <[email protected]> > Subject: Re: [openstack-dev] [kolla] A new kolla-salt deliverable > > Hello, > > Ok this is grey area we haven't had proper discussion yet, I agree. > Since we decided to have separate core teams, I personally don't > really see *why* we should have any form of vote for projects to use > kolla containers. > Things change when we talk about it being kolla deliverable, but what > exactly does that mean? They can use kolla name? Everybody can. They > follow Kolla policies, use Kolla irc channel and have Kolla PTL to > represent them? That's also a choice everybody can make. > > In the spirit of inclusiveness, I'd say keep it free and open. I would > rather have people use kolla name, be open about using kolla > containers and be part of our community. Maybe some sort of "free to > add, but incubate" would be in order, but I personally think that > would be overkill at this stage. > > Thoughts? > > Cheers Michal > > On 23 December 2016 at 05:34, Steven Dake (stdake) <[email protected]> > wrote: > > Michal, > > > > > > > > I was thinking about kolla-salt and our Wednesday team meeting and the > > declaration you made about how it should be done. I personally feel it > is > > mandatory we hold a vote of the core review teams to add a new > deliverable. > > We have voted on the addition of every deliverable we have ever added to > > kolla including application initially to the big tent. I’m in favor of > the > > idea of kolla-salt and it would have my +1 vote. I am not attempting to > > block the addition. It’s more a matter of policies we have established > over > > the last several years. We have also voted to retire deliverables from > the > > Kolla project as well (kolla-mesos and the cli). > > > > > > > > This was easier when there was one core review team. Perhaps a > solution to > > that problem is to make a global core team in gerrit which includes > everyone > > just for policy decisions (such as adding a deliverable). Another > option to > > count whether consensus was reached is to count the core reviewers in > each > > deliverable, divide by two, and determine if consensus is reached. > > > > > > > > If we don’t hold a vote, it looks like a BDFL model that PTLs don’t > operate > > under. Rather PTLs operate under a service model. > > > > > > > > Regards > > > > -steve > > > > > > > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
