cncf-toc@lists.cncf.io

Re: Contour to CNCF sandbox

Gerred Dillon

What are the status of other Envoy-based projects in this space? With Contour asking to skip the SIG process established a few months ago for sandbox - notably recommended by those who are part of this thread - others are being asked to attain, do other ingress projects such as Ambassador have the opportunity to join the sandbox in the same way, or will they need to be part of SIG Network due diligence before becoming a topic for the TOC?

If this group is establishing rules that benefit the larger community and foundation, they should apply to everyone - no matter who proposes it for inclusion, or who tries to skip existing protocol set forth for other projects over the holidays.

Show quoted text

On Jan 7, 2020, at 6:12 PM, Chris Aniszczyk <caniszczyk@...> wrote:

sorry, this is my mistake, I assumed sandbox for contour out of the gate

On Tue, Jan 7, 2020 at 5:11 PM Joe Beda via Lists.Cncf.Io <jbeda=vmware.com@...> wrote:

Ah – my mistake. I know we talked about it. Chris added the “sandbox” label so that confused me. I’ll fix it.

Agree that if we are talking incubation we should definitely have SIG-network start the process.

Sorry for the confusion!

From: Matt Klein <mattklein123@...>
Date: Tuesday, January 7, 2020 at 2:15 PM
To: Joe Beda <jbeda@...>
Cc: "cncf-toc@..." <cncf-toc@...>
Subject: Re: [cncf-toc] Contour to CNCF sandbox

The PR lists incubation as the desired level. So that is not accurate?

On Tue, Jan 7, 2020 at 3:02 PM Joe Beda via Lists.Cncf.Io <jbeda=vmware.com@...> wrote:

Hi all,

I know we’ve talked about not syncing on TOC meetings to get new projects in. As things stand, we have just submitted contour as a sandbox project and there is support from Alexis and Matt and me.

What do we want to consider necessary before we move forward? Do we want to have SIG-network take a look or do we want to just “make it so”?

Personally, I’d be cool with just getting it in but don’t want to jump the gun.

Joe

--
Chris Aniszczyk (@cra) | +1-512-961-6719

KubeCon + CloudNativeCon NA 2019 Conference Transparency Report

Chris Aniszczyk

#4059

The latest conference transparent report is out, enjoy the read!

https://www.cncf.io/blog/2020/01/09/kubecon-cloudnativecon-north-america-2019-conference-transparency-report-the-biggest-kubecon-cloudnativecon-to-date/

--

Chris Aniszczyk (@cra) | +1-512-961-6719

PDF

KubeCon_NA_19_Report.pdf

Re: Comment on Increase Sandbox requirement to three sponsors from the TOC

Vinod

#4058

-1 NB ( I am not in favor of sponsoring concept at all )

I think sponsoring will lead to "King Makers" situation which is against the TOC principle.

I don’t agree that the CNCF sandbox entry barrier is low. Many projects are waiting almost a year to get a “Sponsor”, and others get rejected after a year without getting a “Sponsor”.

I don’t fully agree with the concept that all sandbox projects should graduate. Sandbox then won’t be the ideal name for this stage then. Ideally, all projects should graduate and the CNCF should build sustainable ecosystems for it but there are many other factors that the TOC or CNCF can't control. Projects may go to archives from any stage. The "rkt " project is an example of it.

I agree that the TOC review shouldn’t be a tick-the-box exercise. TOC should make the judgment based on facts, not based on what they like or dislike. A TOC member won’t necessarily get enthusiastic about a project if he/she knows very well about that project's domain and technology stack. Also, the TOC does not pick a “winning stack” as per the TOC's operating principles document.

I have opened an issue in the TOC repo with more details, feel free to comment your thoughts there.

https://github.com/cncf/toc/issues/331

Show quoted text

On Thu, 9 Jan 2020, 16:24 Liz Rice, <liz@...> wrote:

Hi Gerred,

I wanted to follow up with a few thoughts on your comment here.

Although the barrier to entry for Sandbox is intended to be low, we want to make sure that the projects that come in have a good chance of making it to incubation and graduation. Potential sponsors from the TOC should have confidence that the project is on the right path towards those criteria. It would be doing a disservice to a project if we were to accept it without that confidence.

Acceptance to the CNCF at any level should never be just a tick-the-box exercise. The TOC should always be able to exercise their judgement and discretion. At the Sandbox level, if there aren’t enough TOC members with the confidence and enthusiasm in a project to step forward as sponsors, then it doesn’t get accepted.

I hope that helps,
Liz

--
Liz Rice
@lizrice | lizrice.com | +44 (0) 780 126 1145

On 28 Dec 2019, at 06:07, Gerred Dillon <hello@...> wrote:

-1 non-binding

i'm not thrilled with how the sandbox has already changed without a controlled burn rate, i disagree with this motion without other changes to the sandbox process happening. kudo has already been given -1s on sandbox inclusion based on incubating/graduating requirements in private as negative votes for inclusion -- despite communication that these weren't requirements. sandbox is either inclusive or it's not, and i'd rather inclusion at this stage, given there are no marketing expectations or official endorsement of these projects by the CNCF.

On Fri, Dec 27, 2019 at 4:24 PM Thomas Mclennan <Thomas.mc@...> wrote:
+1 non-binding

Comment on Increase Sandbox requirement to three sponsors from the TOC

Liz Rice

#4057

Hi Gerred,

I wanted to follow up with a few thoughts on your comment here.

Although the barrier to entry for Sandbox is intended to be low, we want to make sure that the projects that come in have a good chance of making it to incubation and graduation. Potential sponsors from the TOC should have confidence that the project is on the right path towards those criteria. It would be doing a disservice to a project if we were to accept it without that confidence.

Acceptance to the CNCF at any level should never be just a tick-the-box exercise. The TOC should always be able to exercise their judgement and discretion. At the Sandbox level, if there aren’t enough TOC members with the confidence and enthusiasm in a project to step forward as sponsors, then it doesn’t get accepted.

I hope that helps,

Liz

--

Liz Rice

@lizrice | lizrice.com | +44 (0) 780 126 1145

Show quoted text

On 28 Dec 2019, at 06:07, Gerred Dillon <hello@...> wrote:

-1 non-binding

i'm not thrilled with how the sandbox has already changed without a controlled burn rate, i disagree with this motion without other changes to the sandbox process happening. kudo has already been given -1s on sandbox inclusion based on incubating/graduating requirements in private as negative votes for inclusion -- despite communication that these weren't requirements. sandbox is either inclusive or it's not, and i'd rather inclusion at this stage, given there are no marketing expectations or official endorsement of these projects by the CNCF.

On Fri, Dec 27, 2019 at 4:24 PM Thomas Mclennan <Thomas.mc@...> wrote:
+1 non-binding

[RESULT] Falco Incubation (APPROVED)

Amye Scavarda Perrin

#4056

--

Amye Scavarda Perrin | Program Manager, CNCF | amye@...

Re: Contour to CNCF sandbox

Chris Aniszczyk

#4055

sorry, this is my mistake, I assumed sandbox for contour out of the gate

Show quoted text

On Tue, Jan 7, 2020 at 5:11 PM Joe Beda via Lists.Cncf.Io <jbeda=vmware.com@...> wrote:

Ah – my mistake. I know we talked about it. Chris added the “sandbox” label so that confused me. I’ll fix it.

Agree that if we are talking incubation we should definitely have SIG-network start the process.

Sorry for the confusion!

From: Matt Klein <mattklein123@...>
Date: Tuesday, January 7, 2020 at 2:15 PM
To: Joe Beda <jbeda@...>
Cc: "cncf-toc@..." <cncf-toc@...>
Subject: Re: [cncf-toc] Contour to CNCF sandbox

The PR lists incubation as the desired level. So that is not accurate?

On Tue, Jan 7, 2020 at 3:02 PM Joe Beda via Lists.Cncf.Io <jbeda=vmware.com@...> wrote:

Hi all,

I know we’ve talked about not syncing on TOC meetings to get new projects in. As things stand, we have just submitted contour as a sandbox project and there is support from Alexis and Matt and me.

What do we want to consider necessary before we move forward? Do we want to have SIG-network take a look or do we want to just “make it so”?

Personally, I’d be cool with just getting it in but don’t want to jump the gun.

Joe

--

Chris Aniszczyk (@cra) | +1-512-961-6719

Re: Contour to CNCF sandbox

Joe Beda <jbeda@...>

#4054

Ah – my mistake. I know we talked about it. Chris added the “sandbox” label so that confused me. I’ll fix it.

Agree that if we are talking incubation we should definitely have SIG-network start the process.

Sorry for the confusion!

From: Matt Klein <mattklein123@...>
Date: Tuesday, January 7, 2020 at 2:15 PM
To: Joe Beda <jbeda@...>
Cc: "cncf-toc@..." <cncf-toc@...>
Subject: Re: [cncf-toc] Contour to CNCF sandbox

The PR lists incubation as the desired level. So that is not accurate?

Show quoted text

On Tue, Jan 7, 2020 at 3:02 PM Joe Beda via Lists.Cncf.Io <jbeda=vmware.com@...> wrote:

Hi all,

I know we’ve talked about not syncing on TOC meetings to get new projects in. As things stand, we have just submitted contour as a sandbox project and there is support from Alexis and Matt and me.

What do we want to consider necessary before we move forward? Do we want to have SIG-network take a look or do we want to just “make it so”?

Personally, I’d be cool with just getting it in but don’t want to jump the gun.

Joe

Re: Contour to CNCF sandbox

Matt Klein

#4053

I'd go for Sandbox and figure out details later, but I'm supportive if you want to shoot for incubation and have some good users who can step forward.

+1 but happy to support if you want to try for incubation.

On Tue, Jan 7, 2020 at 3:20 PM Alexis Richardson <alexis@...> wrote:

I'd go for Sandbox and figure out details later, but I'm supportive if you want to shoot for incubation and have some good users who can step forward.

On Tue, 7 Jan 2020, 14:15 Matt Klein, <mattklein123@...> wrote:
The PR lists incubation as the desired level. So that is not accurate?

On Tue, Jan 7, 2020 at 3:02 PM Joe Beda via Lists.Cncf.Io <jbeda=vmware.com@...> wrote:

Hi all,

I know we’ve talked about not syncing on TOC meetings to get new projects in. As things stand, we have just submitted contour as a sandbox project and there is support from Alexis and Matt and me.

What do we want to consider necessary before we move forward? Do we want to have SIG-network take a look or do we want to just “make it so”?

Personally, I’d be cool with just getting it in but don’t want to jump the gun.

Joe

Re: Contour to CNCF sandbox

alexis richardson

#4052

I'd go for Sandbox and figure out details later, but I'm supportive if you want to shoot for incubation and have some good users who can step forward.

Show quoted text

On Tue, 7 Jan 2020, 14:15 Matt Klein, <mattklein123@...> wrote:

The PR lists incubation as the desired level. So that is not accurate?

On Tue, Jan 7, 2020 at 3:02 PM Joe Beda via Lists.Cncf.Io <jbeda=vmware.com@...> wrote:

Hi all,

I know we’ve talked about not syncing on TOC meetings to get new projects in. As things stand, we have just submitted contour as a sandbox project and there is support from Alexis and Matt and me.

What do we want to consider necessary before we move forward? Do we want to have SIG-network take a look or do we want to just “make it so”?

Personally, I’d be cool with just getting it in but don’t want to jump the gun.

Joe

Re: Contour to CNCF sandbox

Matt Klein

#4051

If we are targeting sandbox IMO we can just do it.

If incubation I think we need to route through SIG network (cc @Lee Calcote) for DD.

Show quoted text

On Tue, Jan 7, 2020 at 3:17 PM Joe Beda <jbeda@...> wrote:

Ah – my mistake. I know we talked about it. Chris added the “sandbox” label so that confused me. I’ll fix it.

Agree that if we are talking incubation we should definitely have SIG-network start the process.

Sorry for the confusion!

From: Matt Klein <mattklein123@...>
Date: Tuesday, January 7, 2020 at 2:15 PM
To: Joe Beda <jbeda@...>
Cc: "cncf-toc@..." <cncf-toc@...>
Subject: Re: [cncf-toc] Contour to CNCF sandbox

The PR lists incubation as the desired level. So that is not accurate?

On Tue, Jan 7, 2020 at 3:02 PM Joe Beda via Lists.Cncf.Io <jbeda=vmware.com@...> wrote:

Hi all,

I know we’ve talked about not syncing on TOC meetings to get new projects in. As things stand, we have just submitted contour as a sandbox project and there is support from Alexis and Matt and me.

What do we want to consider necessary before we move forward? Do we want to have SIG-network take a look or do we want to just “make it so”?

Personally, I’d be cool with just getting it in but don’t want to jump the gun.

Joe

Re: Contour to CNCF sandbox

Matt Klein

#4050

The PR lists incubation as the desired level. So that is not accurate?

Show quoted text

On Tue, Jan 7, 2020 at 3:02 PM Joe Beda via Lists.Cncf.Io <jbeda=vmware.com@...> wrote:

Hi all,

I know we’ve talked about not syncing on TOC meetings to get new projects in. As things stand, we have just submitted contour as a sandbox project and there is support from Alexis and Matt and me.

What do we want to consider necessary before we move forward? Do we want to have SIG-network take a look or do we want to just “make it so”?

Personally, I’d be cool with just getting it in but don’t want to jump the gun.

Joe

Contour to CNCF sandbox

Joe Beda <jbeda@...>

#4049

Hi all,

I know we’ve talked about not syncing on TOC meetings to get new projects in. As things stand, we have just submitted contour as a sandbox project and there is support from Alexis and Matt and me.

What do we want to consider necessary before we move forward? Do we want to have SIG-network take a look or do we want to just “make it so”?

Personally, I’d be cool with just getting it in but don’t want to jump the gun.

Joe

Re: An interesting issue wrt CLA

swinslow@...

#4048

Thanks for raising this. In the case of Dependabot, if it is only modifying version numbers and hashes to bump dependency versions, I don't think there is any realistic concern that this bot would be contributing copyrightable content. That might not be the case for other bots but in this case I don't see a concern.

Because of that, from the CNCF / LF side I think we would be comfortable with having Dependabot changes not being blocked by the CLA bot. I'm coordinating with the LF IT team to whitelist Dependabot so that it will not be gated for the k8s CLA bot going forward.

Thanks,
Steve

Re: [EXTERNAL] Re: [cncf-toc] An interesting issue wrt CLA

Matt Farina

#4047

document the desired approach in general.

What is the legal approach for a bot contributing code under a CLA? I'd be curious to know what the guard rails are. Then we can try to make the process as streamlined as possible.

On Tue, Jan 7, 2020, at 2:34 PM, Brendan Burns via Lists.Cncf.Io wrote:

I will definitely ping GitHub folks about this, but I thought it useful to at least document the desired approach in general.

From: cncf-toc@... <cncf-toc@...> on behalf of Matt Farina via Lists.Cncf.Io <matt=mattfarina.com@...>
Sent: Tuesday, January 7, 2020 11:30 AM
To: CNCF TOC <cncf-toc@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: [EXTERNAL] Re: [cncf-toc] An interesting issue wrt CLA

Bots can have delegated authority to sign things on behalf of their makers.

Dependabot is a service now owned by GitHub. Do we want to expect all people offering a service like this to sign the CNCF CLA and associate their bot with it? The person choosing to use the bot is different from those providing it and the person choosing to use it is a member of the project.

Dependabot is automatically generating a PR to update vulnerable dependencies, but of course the CNCF CLA is required

This problem only affects those using the CLA. Dependabot appropriately signs for the DCO. The majority of CNCF projects are not affected by this issue.

It seems like it would be even more important for this kind of a bot to have a signature since if it was compromised or impersonated (can I say that about a bot?) that could be a pretty powerful attack vector.

Dependabot creates a PR like any other random person to come along on GitHub. A person with merge access has to merge the PR and the PR has to pass tests and review as if a person were suggesting the same change. https://dependabot.com/#how-it-works

What would an attack vector for a bot like this be? If a bot had write access to the code I would be concerned.

Any thoughts about the right approach here?

A thought for this case... GitHub is a CNCF member and has a signed CLA (I assume) since GitHub employees contribute to Kubernetes. Is there someone there who can add Dependabots account to the CLA?

This would be the quick and easy approach. It would not scale to similar services.

- Matt Farina

On Tue, Jan 7, 2020, at 2:05 PM, Sarah Allen wrote:
Bots can have delegated authority to sign things on behalf of their makers. It seems like it would be even more important for this kind of a bot to have a signature since if it was compromised or impersonated (can I say that about a bot?) that could be a pretty powerful attack vector.

Thanks for raising this question!

Sarah

On Tue, Jan 7, 2020 at 10:50 AM Brendan Burns via Lists.Cncf.Io <bburns=microsoft.com@...> wrote:
Folks,
See:
https://github.com/kubernetes-client/javascript/pull/384

Dependabot is automatically generating a PR to update vulnerable dependencies, but of course the CNCF CLA is required, and dependabot (being a bot) has no ability to sign.

Any thoughts about the right approach here? (for this specific one I'm going to clone the PR myself, but in general it's an interesting issue)

Thanks
--brendan

Re: [EXTERNAL] Re: [cncf-toc] An interesting issue wrt CLA

Brendan Burns

#4046

I will definitely ping GitHub folks about this, but I thought it useful to at least document the desired approach in general.

Show quoted text

From: cncf-toc@... <cncf-toc@...> on behalf of Matt Farina via Lists.Cncf.Io <matt=mattfarina.com@...>
Sent: Tuesday, January 7, 2020 11:30 AM
To: CNCF TOC <cncf-toc@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: [EXTERNAL] Re: [cncf-toc] An interesting issue wrt CLA

Bots can have delegated authority to sign things on behalf of their makers.

Dependabot is a service now owned by GitHub. Do we want to expect all people offering a service like this to sign the CNCF CLA and associate their bot with it? The person choosing to use the bot is different from those providing it and the person choosing to use it is a member of the project.

Dependabot is automatically generating a PR to update vulnerable dependencies, but of course the CNCF CLA is required

This problem only affects those using the CLA. Dependabot appropriately signs for the DCO. The majority of CNCF projects are not affected by this issue.

It seems like it would be even more important for this kind of a bot to have a signature since if it was compromised or impersonated (can I say that about a bot?) that could be a pretty powerful attack vector.

Dependabot creates a PR like any other random person to come along on GitHub. A person with merge access has to merge the PR and the PR has to pass tests and review as if a person were suggesting the same change. https://dependabot.com/#how-it-works

What would an attack vector for a bot like this be? If a bot had write access to the code I would be concerned.

Any thoughts about the right approach here?

A thought for this case... GitHub is a CNCF member and has a signed CLA (I assume) since GitHub employees contribute to Kubernetes. Is there someone there who can add Dependabots account to the CLA?

This would be the quick and easy approach. It would not scale to similar services.

- Matt Farina

On Tue, Jan 7, 2020, at 2:05 PM, Sarah Allen wrote:

Bots can have delegated authority to sign things on behalf of their makers. It seems like it would be even more important for this kind of a bot to have a signature since if it was compromised or impersonated (can I say that about a bot?) that could be a pretty powerful attack vector.

Thanks for raising this question!

Sarah

On Tue, Jan 7, 2020 at 10:50 AM Brendan Burns via Lists.Cncf.Io <bburns=microsoft.com@...> wrote:

Folks,

See:

https://github.com/kubernetes-client/javascript/pull/384

Dependabot is automatically generating a PR to update vulnerable dependencies, but of course the CNCF CLA is required, and dependabot (being a bot) has no ability to sign.

Any thoughts about the right approach here? (for this specific one I'm going to clone the PR myself, but in general it's an interesting issue)

Thanks

--brendan

Re: An interesting issue wrt CLA

Matt Farina

#4045

Bots can have delegated authority to sign things on behalf of their makers.

Dependabot is a service now owned by GitHub. Do we want to expect all people offering a service like this to sign the CNCF CLA and associate their bot with it? The person choosing to use the bot is different from those providing it and the person choosing to use it is a member of the project.

Dependabot is automatically generating a PR to update vulnerable dependencies, but of course the CNCF CLA is required

This problem only affects those using the CLA. Dependabot appropriately signs for the DCO. The majority of CNCF projects are not affected by this issue.

It seems like it would be even more important for this kind of a bot to have a signature since if it was compromised or impersonated (can I say that about a bot?) that could be a pretty powerful attack vector.

Dependabot creates a PR like any other random person to come along on GitHub. A person with merge access has to merge the PR and the PR has to pass tests and review as if a person were suggesting the same change. https://dependabot.com/#how-it-works

What would an attack vector for a bot like this be? If a bot had write access to the code I would be concerned.

Any thoughts about the right approach here?

A thought for this case... GitHub is a CNCF member and has a signed CLA (I assume) since GitHub employees contribute to Kubernetes. Is there someone there who can add Dependabots account to the CLA?

This would be the quick and easy approach. It would not scale to similar services.

- Matt Farina

On Tue, Jan 7, 2020, at 2:05 PM, Sarah Allen wrote:

Bots can have delegated authority to sign things on behalf of their makers. It seems like it would be even more important for this kind of a bot to have a signature since if it was compromised or impersonated (can I say that about a bot?) that could be a pretty powerful attack vector.

Thanks for raising this question!

Sarah

On Tue, Jan 7, 2020 at 10:50 AM Brendan Burns via Lists.Cncf.Io <bburns=microsoft.com@...> wrote:
Folks,
See:
https://github.com/kubernetes-client/javascript/pull/384

Dependabot is automatically generating a PR to update vulnerable dependencies, but of course the CNCF CLA is required, and dependabot (being a bot) has no ability to sign.

Any thoughts about the right approach here? (for this specific one I'm going to clone the PR myself, but in general it's an interesting issue)

Thanks
--brendan

Re: [VOTE] SIG Runtime

Hong Zhang <cathy.zhang@...>

#4044

+1 NB 

Cheers,
Cathy Zhang

On 6 January 2020 at 21:39:42, Amye Scavarda Perrin (ascavarda@...) wrote:
A new CNCF Runtime SIG has been proposed with Brian Grant and Brendan 
Burns as the TOC liaisons.

Co-Chairs: Quinton Hoole, Ricardo Aravena, with one more to be added.
Tech Leads to be decided in the future.

Please vote (+1/0/-1) by replying to this thread; the full proposal 
located
here: 
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
ub.com%2Fcncf%2Ftoc%2Fpull%2F319&amp;data=02%7C01%7Ccathy.zhang%40futu
rewei.com%7C4b93f7e969a645a1111608d79397d3b5%7C0fee8ff2a3b240189c753a1
d5591fedc%7C1%7C1%7C637140152625209879&amp;sdata=mmY99tBGcY57h58M5Fxox
4niQ6POwMiJeMMJuAtkj%2Bc%3D&amp;reserved=0

Remember that the TOC has binding votes only, but we do appreciate 
non-binding votes from the community as a sign of support!

--
Amye Scavarda Perrin | Program Manager, CNCF | 
amye@...



Amazon Data Services Ireland Limited registered office: One Burlington Plaza, Burlington Road, Dublin 4, Ireland. Registered in Ireland. Registration number 390566.

Re: An interesting issue wrt CLA

Sarah Allen

#4043

Bots can have delegated authority to sign things on behalf of their makers. It seems like it would be even more important for this kind of a bot to have a signature since if it was compromised or impersonated (can I say that about a bot?) that could be a pretty powerful attack vector.

Thanks for raising this question!

Sarah

Show quoted text

On Tue, Jan 7, 2020 at 10:50 AM Brendan Burns via Lists.Cncf.Io <bburns=microsoft.com@...> wrote:

Folks,

See:

https://github.com/kubernetes-client/javascript/pull/384

Dependabot is automatically generating a PR to update vulnerable dependencies, but of course the CNCF CLA is required, and dependabot (being a bot) has no ability to sign.

Any thoughts about the right approach here? (for this specific one I'm going to clone the PR myself, but in general it's an interesting issue)

Thanks

--brendan

An interesting issue wrt CLA

Brendan Burns

#4042

Folks,

See:

https://github.com/kubernetes-client/javascript/pull/384

Dependabot is automatically generating a PR to update vulnerable dependencies, but of course the CNCF CLA is required, and dependabot (being a bot) has no ability to sign.

Any thoughts about the right approach here? (for this specific one I'm going to clone the PR myself, but in general it's an interesting issue)

Thanks

--brendan

Re: [VOTE] SIG Runtime

Kiran Mova

#4041

+1 NB

--

Kiran Mova | Co-Founder, Chief Architect MayaData | kiran.mova@...

https://github.com/openebs/openebs

Show quoted text

On Tue, Jan 7, 2020 at 11:04 PM Hausenblas, Michael via Lists.Cncf.Io <hausenbl=amazon.com@...> wrote:

+1 (nb)

Cheers,
Michael

--

Developer Advocate @ AWS
+353 86 0215164

On 6 January 2020 at 21:39:42, Amye Scavarda Perrin (ascavarda@...) wrote:
> A new CNCF Runtime SIG has been proposed with Brian Grant and Brendan Burns
> as the TOC liaisons.
>
> Co-Chairs: Quinton Hoole, Ricardo Aravena, with one more to be added.
> Tech Leads to be decided in the future.
>
> Please vote (+1/0/-1) by replying to this thread; the full proposal located
> here: https://github.com/cncf/toc/pull/319
>
> Remember that the TOC has binding votes only, but we do appreciate
> non-binding votes from the community as a sign of support!
>
> --
> Amye Scavarda Perrin | Program Manager, CNCF | amye@...
>
>
>
>
Amazon Data Services Ireland Limited registered office: One Burlington Plaza, Burlington Road, Dublin 4, Ireland. Registered in Ireland. Registration number 390566.