Date   

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

Vinod
 

-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.



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
 

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





[RESULT] Falco Incubation (APPROVED)

Amye Scavarda Perrin
 

The Falco project has been approved to the incubating maturity level:
https://github.com/cncf/toc/pull/307

+1 binding TOC votes (7/9):
Matt Klein: https://lists.cncf.io/g/cncf-toc/message/3922
Michelle Noorali: https://lists.cncf.io/g/cncf-toc/message/3931
Joe Beda: https://lists.cncf.io/g/cncf-toc/message/3952
Jeff Brewer: https://lists.cncf.io/g/cncf-toc/message/3963
Xiang Li: https://lists.cncf.io/g/cncf-toc/message/3967
Liz Rice: https://lists.cncf.io/g/cncf-toc/message/3968
Alexis Richardson: https://lists.cncf.io/g/cncf-toc/message/3970

+1 non-binding community votes:
Ken Owens: https://lists.cncf.io/g/cncf-toc/message/3785
Farhad Arshad: https://lists.cncf.io/g/cncf-toc/message/3786
Roger Klorese: https://lists.cncf.io/g/cncf-toc/message/3787
Gaurav Garg: https://lists.cncf.io/g/cncf-toc/message/3788
Mark Stemm: https://lists.cncf.io/g/cncf-toc/message/3790
Radhika Puthiyetath: https://lists.cncf.io/g/cncf-toc/message/3791
Justin Cormack: https://lists.cncf.io/g/cncf-toc/message/3792
Matthew Caya: https://lists.cncf.io/g/cncf-toc/message/3793
Chris Short: https://lists.cncf.io/g/cncf-toc/message/3794
Gareth Rushgrove: https://lists.cncf.io/g/cncf-toc/message/3800
Johan Tordsson: https://lists.cncf.io/g/cncf-toc/message/3801
Rishi Divate: https://lists.cncf.io/g/cncf-toc/message/3860
Jon Mittelhauser: https://lists.cncf.io/g/cncf-toc/message/3861
Iftach Schonbaum: https://lists.cncf.io/g/cncf-toc/message/3862
Kasper Nissen: https://lists.cncf.io/g/cncf-toc/message/3863
Siddharth Bhadri: https://lists.cncf.io/g/cncf-toc/message/3864
Johan Tordsson: https://lists.cncf.io/g/cncf-toc/message/3865
Stephen Augustus: https://lists.cncf.io/g/cncf-toc/message/3925
Brandon Lum: https://lists.cncf.io/g/cncf-toc/message/3926
Philippe Robin: https://lists.cncf.io/g/cncf-toc/message/3927
Golfen Guo: https://lists.cncf.io/g/cncf-toc/message/3932
Max Körbächer: https://lists.cncf.io/g/cncf-toc/message/3934
Jeyappragash Jeyakeerthi: https://lists.cncf.io/g/cncf-toc/message/3964
Liam Randall: https://lists.cncf.io/g/cncf-toc/message/3965
Lee Calcote: https://lists.cncf.io/g/cncf-toc/message/3987

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


Re: Contour to CNCF sandbox

Chris Aniszczyk
 

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


Re: Contour to CNCF sandbox

Joe Beda <jbeda@...>
 

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
 

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
 

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

Matt Klein
 

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.

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
 

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


Contour to CNCF sandbox

Joe Beda <jbeda@...>
 

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@...
 

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
 

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:

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
 

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:

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
 

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:

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@...>
 

+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
 

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:

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
 

Folks,
See:

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
 

+1 NB


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.




Re: [VOTE] SIG Runtime

Hausenblas, Michael
 

+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.


Re: [EXTERNAL] Re: [cncf-toc] [VOTE] SIG Runtime

Li, Xiang
 

------------------------------------------------------------------
发件人:Brendan Burns via Lists.Cncf.Io<bburns=microsoft.com@...>
日 期:2020年01月08日 01:21:26
收件人:briangrant@...<briangrant@...>; Liz Rice<liz@...>
抄 送:<cncf-toc@...>
主 题:Re: [EXTERNAL] Re: [cncf-toc] [VOTE] SIG Runtime

+1, binding

--brendan


From: cncf-toc@... <cncf-toc@...> on behalf of Brian Grant via Lists.Cncf.Io <briangrant=google.com@...>
Sent: Tuesday, January 7, 2020 8:25:17 AM
To: Liz Rice <liz@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: [EXTERNAL] Re: [cncf-toc] [VOTE] SIG Runtime
 
+1 binding

On Tue, Jan 7, 2020 at 6:49 AM Liz Rice <liz@...> wrote:
+1 binding (on the assumption the minor details in the PR get addressed) 

--
Liz Rice
@lizrice | lizrice.com | +44 (0) 780 126 1145
On 7 Jan 2020, 14:00 +0000, Pengfei Ni , wrote:
+1 nb


Best regards.


---
Pengfei Ni



Amye Scavarda Perrin <ascavarda@...> 于2020年1月7日周二 上午5:39写道:
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@...


3281 - 3300 of 7334