Re: [EXTERNAL] [cncf-toc] What do we mean by “Version 1.0”?
I think there is some nuance in here but it's worth discussing.
For example, if a project is using SemVer there are a couple parts of the spec that come to mind...
4. Major version zero (0.y.z) is for initial development.
If a project doesn't have a 1.0.0 yet and it's using SemVer than I don't think it should be graduated because it's still in initial development.
I realize different people do different things with versions. But, versions are about communication. Graduated projects should be clear on their communication of versions.
1. Software using Semantic Versioning MUST declare a public API.
and
8. Major version X (X.y.z | X > 0) MUST be incremented if any backwards
incompatible changes are introduced to the public API.
and on the CNCF projects page it talks about Graduated Projects being for the majority. They aren't experiments but things that more cautious businesses can adopt.
A graduated project should state what it's API is (network, library interface, UI output, etc) and then properly version that so that consumers can know what they are getting and when things will change.
These are policy based and different projects can do different things. For example, Kubernetes does not follow SemVer but does specify what is in the supported API policy and how it changes. Helm does something similar with the Go API and output from helm commands. For example, on Helm we have one place where the date format is different from the rest in the output but we can't change that until Helm v4 as a default because we know external tools parse that output.
I would expect graduated projects to do things in a way that communicates clearly on what's happening with versions and have stable releases.
Just my 2 cents.
- Matt Farina
On Thu, Jan 14, 2021, at 1:33 PM, alexis richardson wrote:
IMO, everyone's using version numbers in different ways now. For example many projects go to 1.0 once they are feature complete, and hit production way before that. I think insisting on 1.0 for graduation is unfair and not very helpful.
I realise that many enterprise users still see 1.0 as being the first production ready version. Much as Quinton says.
So, I suggest we leave everything as it is, and make sure that our own graduation criteria are clear.
On Thu, 14 Jan 2021, 18:27 Quinton Hoole, < quinton@...> wrote: I'm not convinced that in people's minds, or practically, v1.0 and Graduated mean similar things. As a concrete example, Kubernetes went to v 1.0 several years before it graduated. In my mind, version numbers tend to denote the maturity of the software. Graduation levels add to that the maturity of the process and community around the software.
I do however think that there would be value striving for some amount of consistency in the semantics of version numbering across CNCF projects (possibly) to avoid the kind of confusion that Liz ran into. I don't know exactly what that would look like, but I imagine something along the lines of:
- pre 1.0 denotes "not recommended for production use"
- post x.y denotes "go for it, people are starting to use it successfully in production"
- post p.q denotes "rock solid, widely used in production - almost definitely graduated unless there are extenuating circumstances"
... and so on might make sense.
This detail may well have been debated in depth elsewhere in the CNCF, in which case I apologise for not being up to speed on that :-)
Q
+1 imo a graduated project should have some documented backward compatibility guarantees and semantic versioning helps denote this. It has been a best practice on all the projects I've worked on. I'd be supportive of adding a criteria around stability and defining
what that means and recommending using a semantic version to denote this for graduation.
Hi folks,
Someone I spoke with today said something along the lines “if <this project> is stable, why is it still at v0.something?” and that got me thinking - does it make any sense to expect Graduated projects to be at v1.0 or above?
I know this is easily gamed, in the sense that project maintainers can release any version number they like, but let’s set that aside for now and assume that maintainers are well intentioned. I wonder if the signals that are sent by releasing
a v1.0 are similar to what Graduation means?
(I have not checked the version numbers of existing graduated projects)
Thoughts?
Liz
--
|
|
Re: [EXTERNAL] [cncf-toc] What do we mean by “Version 1.0”?
IMO, everyone's using version numbers in different ways now. For example many projects go to 1.0 once they are feature complete, and hit production way before that. I think insisting on 1.0 for graduation is unfair and not very helpful.
I realise that many enterprise users still see 1.0 as being the first production ready version. Much as Quinton says.
So, I suggest we leave everything as it is, and make sure that our own graduation criteria are clear.
toggle quoted message
Show quoted text
On Thu, 14 Jan 2021, 18:27 Quinton Hoole, < quinton@...> wrote: I'm not convinced that in people's minds, or practically, v1.0 and Graduated mean similar things. As a concrete example, Kubernetes went to v 1.0 several years before it graduated. In my mind, version numbers tend to denote the maturity of the software. Graduation levels add to that the maturity of the process and community around the software.
I do however think that there would be value striving for some amount of consistency in the semantics of version numbering across CNCF projects (possibly) to avoid the kind of confusion that Liz ran into. I don't know exactly what that would look like, but I imagine something along the lines of:
- pre 1.0 denotes "not recommended for production use" - post x.y denotes "go for it, people are starting to use it successfully in production" - post p.q denotes "rock solid, widely used in production - almost definitely graduated unless there are extenuating circumstances"
... and so on might make sense.
This detail may well have been debated in depth elsewhere in the CNCF, in which case I apologise for not being up to speed on that :-)
Q
+1 imo a graduated project should have some documented backward compatibility guarantees and semantic versioning helps denote this. It has been a best practice on all the projects I've worked on. I'd be supportive of adding a criteria around stability and defining
what that means and recommending using a semantic version to denote this for graduation.
Hi folks,
Someone I spoke with today said something along the lines “if <this project> is stable, why is it still at v0.something?” and that got me thinking - does it make any sense to expect Graduated projects to be at v1.0 or above?
I know this is easily gamed, in the sense that project maintainers can release any version number they like, but let’s set that aside for now and assume that maintainers are well intentioned. I wonder if the signals that are sent by releasing
a v1.0 are similar to what Graduation means?
(I have not checked the version numbers of existing graduated projects)
Thoughts?
Liz
--
|
|
Re: [EXTERNAL] [cncf-toc] What do we mean by “Version 1.0”?
Quinton Hoole <quinton@...>
I'm not convinced that in people's minds, or practically, v1.0 and Graduated mean similar things. As a concrete example, Kubernetes went to v 1.0 several years before it graduated. In my mind, version numbers tend to denote the maturity of the software. Graduation levels add to that the maturity of the process and community around the software.
I do however think that there would be value striving for some amount of consistency in the semantics of version numbering across CNCF projects (possibly) to avoid the kind of confusion that Liz ran into. I don't know exactly what that would look like, but I imagine something along the lines of:
- pre 1.0 denotes "not recommended for production use" - post x.y denotes "go for it, people are starting to use it successfully in production" - post p.q denotes "rock solid, widely used in production - almost definitely graduated unless there are extenuating circumstances"
... and so on might make sense.
This detail may well have been debated in depth elsewhere in the CNCF, in which case I apologise for not being up to speed on that :-)
Q
toggle quoted message
Show quoted text
+1 imo a graduated project should have some documented backward compatibility guarantees and semantic versioning helps denote this. It has been a best practice on all the projects I've worked on. I'd be supportive of adding a criteria around stability and defining
what that means and recommending using a semantic version to denote this for graduation.
Hi folks,
Someone I spoke with today said something along the lines “if <this project> is stable, why is it still at v0.something?” and that got me thinking - does it make any sense to expect Graduated projects to be at v1.0 or above?
I know this is easily gamed, in the sense that project maintainers can release any version number they like, but let’s set that aside for now and assume that maintainers are well intentioned. I wonder if the signals that are sent by releasing
a v1.0 are similar to what Graduation means?
(I have not checked the version numbers of existing graduated projects)
Thoughts?
Liz
|
|
Re: [EXTERNAL] [cncf-toc] What do we mean by “Version 1.0”?
+1 imo a graduated project should have some documented backward compatibility guarantees and semantic versioning helps denote this. It has been a best practice on all the projects I've worked on. I'd be supportive of adding a criteria around stability and defining
what that means and recommending using a semantic version to denote this for graduation.
toggle quoted message
Show quoted text
From: cncf-toc@... <cncf-toc@...> on behalf of Liz Rice via lists.cncf.io <liz=lizrice.com@...>
Sent: Thursday, January 14, 2021 12:26 PM
To: cncf-toc@... <cncf-toc@...>
Subject: [EXTERNAL] [cncf-toc] What do we mean by “Version 1.0”?
Hi folks,
Someone I spoke with today said something along the lines “if <this project> is stable, why is it still at v0.something?” and that got me thinking - does it make any sense to expect Graduated projects to be at v1.0 or above?
I know this is easily gamed, in the sense that project maintainers can release any version number they like, but let’s set that aside for now and assume that maintainers are well intentioned. I wonder if the signals that are sent by releasing
a v1.0 are similar to what Graduation means?
(I have not checked the version numbers of existing graduated projects)
Thoughts?
Liz
|
|
What do we mean by “Version 1.0”?
Hi folks,
Someone I spoke with today said something along the lines “if <this project> is stable, why is it still at v0.something?” and that got me thinking - does it make any sense to expect Graduated projects to be at v1.0 or above?
I know this is easily gamed, in the sense that project maintainers can release any version number they like, but let’s set that aside for now and assume that maintainers are well intentioned. I wonder if the signals that are sent by releasing a v1.0 are similar to what Graduation means?
(I have not checked the version numbers of existing graduated projects)
Thoughts?
Liz
|
|
Re: SIG-Security Tech Lead nominations
RESULT:
Welcome new tech leads!
toggle quoted message
Show quoted text
On Thu, Dec 17, 2020 at 5:43 PM Jeyappragash Jeyakeerthi < jj@...> wrote: Dear Technical Oversight Committee, On December 16th 2020, the SIG-Security co-chairs along with then TOC liason’s Liz Rice and Justin Cormack, agreed to nominate three Tech Leads for SIG-Security: Ashutosh Narkar, Aradhana Chetal and Andres Vega. “Tech leads are assigned following a 2/3 majority vote of the TOC and a 2/3 majority vote of SIG Chairs” — cncf-sig elections Thank you!
Jeyappragash.J.J (On behalf of SIG-Security Chairs)
TL Candidates - Dec 2020
Ashutosh Narkar
Aradhana Chetal
Andres Vega
-- Amye Scavarda Perrin | Program Manager | amye@...
|
|
Re: SIG-Security Tech Lead nominations
Magno Logan <magno.logan@...>
toggle quoted message
Show quoted text
+1 binding
On Thu, Dec 17, 2020 at 5:43 PM Jeyappragash Jeyakeerthi < jj@...> wrote: Dear Technical Oversight Committee, On December 16th 2020, the SIG-Security co-chairs along with then TOC liason’s Liz Rice and Justin Cormack, agreed to nominate three Tech Leads for SIG-Security: Ashutosh Narkar, Aradhana Chetal and Andres Vega. “Tech leads are assigned following a 2/3 majority vote of the TOC and a 2/3 majority vote of SIG Chairs” — cncf-sig elections Thank you!
Jeyappragash.J.J (On behalf of SIG-Security Chairs)
TL Candidates - Dec 2020
Ashutosh Narkar
Aradhana Chetal
Andres Vega
|
|
Re: Public comment period for Ambassador
Ah, ok. Sorry, my mistake!
toggle quoted message
Show quoted text
It wasn't in the sandbox, they went straight for incubation: https://github.com/datawire/ambassador
I know it can be confusing as they were originally considered a sandbox contribution but decided to go straight for incubation.
We will work with the project and come up with a new name based on this feedback.
On Thu, Jan 7, 2021 at 12:25 PM Liz Rice < liz@...> wrote: This question is probably six months too late, but didn't CNCF own the Ambasaador trademark (since the project joined Sandbox)?
On Thu, 7 Jan 2021 at 18:08, Joe Beda < joe@...> wrote: Personally I disagree that this is akin to asking for a license change.
The name is an intrinsic part of the project. It is the primary key for the community. This feels more like accepting a fork (well, I'm assuming there is no divergence) while the original project stays with the commercial entity. Personally, I'm interested to see how much of a community is left after the name change and how much of that community is attached to the commercial entity named "Ambassador".
On Thu, Jan 7, 2021 at 10:04 AM Chris Aniszczyk < caniszczyk@...> wrote: I don't think we have to fully pause everything but it's up to the TOC here, if the TOC is saying "choose another name than IC4EP or something else that wouldn't confuse end users" before we accept the project fully then the project can do that in parallel as we onboard it as part of staff duties. We can work with the project to pick up a name and run it by the TOC again.
IMHO I view this a bit similar to a project coming in that may have to change a license to Apache-2 etc (like grpc did as an example), just part of the onboarding process.
OK then IMO we have to pause this for a bit. Can we finalize the name, get it fully done, and then re-submit the DD with the new name, website, etc. clearly in place?
On Thu, Jan 7, 2021 at 9:55 AM Chris Aniszczyk < caniszczyk@...> wrote: The problem is the company rebranded to Ambassador also here: https://www.getambassador.io, so the project needs to be renamed to deal with the obvious trademark conflict here. The CNCF is open to whatever the project decides and that clears a trademark search.
Also, to be clear, I think Ambassador is a big part of the OSS brand and I had erroneously thought that we were sticking with that name. If we are going to change the name to something entirely new it might be good to do that and then circle back in a few months to see how it's going.
I'm sorry for not tracking this more closely, but I agree with Joe on this. I'm not OK with an acronym for something that IMO is too generic. I think you either have to stick with Ambassador or choose an entirely new name.
On Thu, Jan 7, 2021 at 9:37 AM Joe Beda < joe@...> wrote: IC4E only begs the question about what it stands for. It also doesn't set the project up, IMO, for success as the more memorable name will be with the commercial entity and it could stunt the development of the open source project outside of the commercial attachments. If this were at the Sandbox level I probably wouldn't be bringing this up, but the name change along with introduction into Incubation is something new that the CNCF hasn't seen before. I worry people will still colloquially refer to the OSS project as "Ambassador" (and documentation and install scripts still use the name).
Hi Joe, Matt, many thanks for your comments.
@Matt, I remember you raising this in the DD document comments,
and @Chris Aniszczyk suggested this would be acceptable under the
trademark policy (e.g. "X for Envoy"). He suggested that we use a
short name like "IC4E" in the docs and new website that would be
created for the project.
We originally looked to ingress-nginx as inspiration, since the
community seems to have accepted this as a name even though it’s
well-understood it’s not “official”. We also wanted to with a
descriptive name instead of an abstract name, because we thought
it would be easier for people to understand.
Best wishes,
Daniel
On 06/01/2021 19:54, Matt Klein wrote:
> I object to the name "Ingress Controller for
Envoy Proxy” as that also describes Contour. This will create
confusion and will be easily misread as "THE Ingress Controller
for Envoy Proxy" and will violate the "no kingmakers" value of
the TOC.
I agree and I raised a similar concern at some point but I
don't remember the outcome here. @Daniel Bryant?
On Wed, Jan 6, 2021 at 10:48
AM Joe Beda < joe@...> wrote:
What is the new name? The name "ambassador" is
all over the docs and I'd expect to see this reframed around
the new name.
I object to the name "Ingress Controller for Envoy
Proxy” as that also describes Contour. This will create
confusion and will be easily misread as "THE Ingress
Controller for Envoy Proxy" and will violate the "no
kingmakers" value of the TOC.
Joe
All,
Ambassador is applying for incubation status:
DD has been reviewed by myself and SIG Network
and we are supportive. We are now calling for the 2
week public comment period prior to the vote.
Thanks,
Matt
--
Daniel Bryant | @danielbryantuk
--
I like to work flexible hours (and across time zones), but please don't feel obligated to reply to this message outside of your own working hours.
--
--
--
|
|
Re: SIG-Security Tech Lead nominations
toggle quoted message
Show quoted text
On Thu, Dec 17, 2020 at 5:43 PM Jeyappragash Jeyakeerthi < jj@...> wrote: Dear Technical Oversight Committee, On December 16th 2020, the SIG-Security co-chairs along with then TOC liason’s Liz Rice and Justin Cormack, agreed to nominate three Tech Leads for SIG-Security: Ashutosh Narkar, Aradhana Chetal and Andres Vega. “Tech leads are assigned following a 2/3 majority vote of the TOC and a 2/3 majority vote of SIG Chairs” — cncf-sig elections Thank you!
Jeyappragash.J.J (On behalf of SIG-Security Chairs)
TL Candidates - Dec 2020
Ashutosh Narkar
Aradhana Chetal
Andres Vega
|
|
Re: Public comment period for Ambassador

Chris Aniszczyk
It wasn't in the sandbox, they went straight for incubation: https://github.com/datawire/ambassador
I know it can be confusing as they were originally considered a sandbox contribution but decided to go straight for incubation.
We will work with the project and come up with a new name based on this feedback.
toggle quoted message
Show quoted text
On Thu, Jan 7, 2021 at 12:25 PM Liz Rice < liz@...> wrote: This question is probably six months too late, but didn't CNCF own the Ambasaador trademark (since the project joined Sandbox)?
On Thu, 7 Jan 2021 at 18:08, Joe Beda < joe@...> wrote: Personally I disagree that this is akin to asking for a license change.
The name is an intrinsic part of the project. It is the primary key for the community. This feels more like accepting a fork (well, I'm assuming there is no divergence) while the original project stays with the commercial entity. Personally, I'm interested to see how much of a community is left after the name change and how much of that community is attached to the commercial entity named "Ambassador".
On Thu, Jan 7, 2021 at 10:04 AM Chris Aniszczyk < caniszczyk@...> wrote: I don't think we have to fully pause everything but it's up to the TOC here, if the TOC is saying "choose another name than IC4EP or something else that wouldn't confuse end users" before we accept the project fully then the project can do that in parallel as we onboard it as part of staff duties. We can work with the project to pick up a name and run it by the TOC again.
IMHO I view this a bit similar to a project coming in that may have to change a license to Apache-2 etc (like grpc did as an example), just part of the onboarding process.
OK then IMO we have to pause this for a bit. Can we finalize the name, get it fully done, and then re-submit the DD with the new name, website, etc. clearly in place?
On Thu, Jan 7, 2021 at 9:55 AM Chris Aniszczyk < caniszczyk@...> wrote: The problem is the company rebranded to Ambassador also here: https://www.getambassador.io, so the project needs to be renamed to deal with the obvious trademark conflict here. The CNCF is open to whatever the project decides and that clears a trademark search.
Also, to be clear, I think Ambassador is a big part of the OSS brand and I had erroneously thought that we were sticking with that name. If we are going to change the name to something entirely new it might be good to do that and then circle back in a few months to see how it's going.
I'm sorry for not tracking this more closely, but I agree with Joe on this. I'm not OK with an acronym for something that IMO is too generic. I think you either have to stick with Ambassador or choose an entirely new name.
On Thu, Jan 7, 2021 at 9:37 AM Joe Beda < joe@...> wrote: IC4E only begs the question about what it stands for. It also doesn't set the project up, IMO, for success as the more memorable name will be with the commercial entity and it could stunt the development of the open source project outside of the commercial attachments. If this were at the Sandbox level I probably wouldn't be bringing this up, but the name change along with introduction into Incubation is something new that the CNCF hasn't seen before. I worry people will still colloquially refer to the OSS project as "Ambassador" (and documentation and install scripts still use the name).
Hi Joe, Matt, many thanks for your comments.
@Matt, I remember you raising this in the DD document comments,
and @Chris Aniszczyk suggested this would be acceptable under the
trademark policy (e.g. "X for Envoy"). He suggested that we use a
short name like "IC4E" in the docs and new website that would be
created for the project.
We originally looked to ingress-nginx as inspiration, since the
community seems to have accepted this as a name even though it’s
well-understood it’s not “official”. We also wanted to with a
descriptive name instead of an abstract name, because we thought
it would be easier for people to understand.
Best wishes,
Daniel
On 06/01/2021 19:54, Matt Klein wrote:
> I object to the name "Ingress Controller for
Envoy Proxy” as that also describes Contour. This will create
confusion and will be easily misread as "THE Ingress Controller
for Envoy Proxy" and will violate the "no kingmakers" value of
the TOC.
I agree and I raised a similar concern at some point but I
don't remember the outcome here. @Daniel Bryant?
On Wed, Jan 6, 2021 at 10:48
AM Joe Beda < joe@...> wrote:
What is the new name? The name "ambassador" is
all over the docs and I'd expect to see this reframed around
the new name.
I object to the name "Ingress Controller for Envoy
Proxy” as that also describes Contour. This will create
confusion and will be easily misread as "THE Ingress
Controller for Envoy Proxy" and will violate the "no
kingmakers" value of the TOC.
Joe
All,
Ambassador is applying for incubation status:
DD has been reviewed by myself and SIG Network
and we are supportive. We are now calling for the 2
week public comment period prior to the vote.
Thanks,
Matt
--
Daniel Bryant | @danielbryantuk
--
I like to work flexible hours (and across time zones), but please don't feel obligated to reply to this message outside of your own working hours.
--
--
|
|
Re: SIG-Security Tech Lead nominations
Michelle Noorali <michelle.noorali@...>
toggle quoted message
Show quoted text
On Wed, Jan 6, 2021 at 3:28 PM Dan Shaw < dshaw@...> wrote: +1 NB
Thank you Ashutosh Narkar, Aradhana Chetal and Andres Vega for all the hard work advancing SIG-Security.
Dan ShawCor.dev - Solving Solved Problems 💗
On Thu, Dec 17, 2020 at 5:43 PM Jeyappragash Jeyakeerthi < jj@...> wrote: Dear Technical Oversight Committee, On December 16th 2020, the SIG-Security co-chairs along with then TOC liason’s Liz Rice and Justin Cormack, agreed to nominate three Tech Leads for SIG-Security: Ashutosh Narkar, Aradhana Chetal and Andres Vega. “Tech leads are assigned following a 2/3 majority vote of the TOC and a 2/3 majority vote of SIG Chairs” — cncf-sig elections Thank you!
Jeyappragash.J.J (On behalf of SIG-Security Chairs)
TL Candidates - Dec 2020
Ashutosh Narkar
Aradhana Chetal
Andres Vega
|
|
Re: Public comment period for Ambassador
This question is probably six months too late, but didn't CNCF own the Ambasaador trademark (since the project joined Sandbox)?
toggle quoted message
Show quoted text
On Thu, 7 Jan 2021 at 18:08, Joe Beda < joe@...> wrote: Personally I disagree that this is akin to asking for a license change.
The name is an intrinsic part of the project. It is the primary key for the community. This feels more like accepting a fork (well, I'm assuming there is no divergence) while the original project stays with the commercial entity. Personally, I'm interested to see how much of a community is left after the name change and how much of that community is attached to the commercial entity named "Ambassador".
On Thu, Jan 7, 2021 at 10:04 AM Chris Aniszczyk < caniszczyk@...> wrote: I don't think we have to fully pause everything but it's up to the TOC here, if the TOC is saying "choose another name than IC4EP or something else that wouldn't confuse end users" before we accept the project fully then the project can do that in parallel as we onboard it as part of staff duties. We can work with the project to pick up a name and run it by the TOC again.
IMHO I view this a bit similar to a project coming in that may have to change a license to Apache-2 etc (like grpc did as an example), just part of the onboarding process.
OK then IMO we have to pause this for a bit. Can we finalize the name, get it fully done, and then re-submit the DD with the new name, website, etc. clearly in place?
On Thu, Jan 7, 2021 at 9:55 AM Chris Aniszczyk < caniszczyk@...> wrote: The problem is the company rebranded to Ambassador also here: https://www.getambassador.io, so the project needs to be renamed to deal with the obvious trademark conflict here. The CNCF is open to whatever the project decides and that clears a trademark search.
Also, to be clear, I think Ambassador is a big part of the OSS brand and I had erroneously thought that we were sticking with that name. If we are going to change the name to something entirely new it might be good to do that and then circle back in a few months to see how it's going.
I'm sorry for not tracking this more closely, but I agree with Joe on this. I'm not OK with an acronym for something that IMO is too generic. I think you either have to stick with Ambassador or choose an entirely new name.
On Thu, Jan 7, 2021 at 9:37 AM Joe Beda < joe@...> wrote: IC4E only begs the question about what it stands for. It also doesn't set the project up, IMO, for success as the more memorable name will be with the commercial entity and it could stunt the development of the open source project outside of the commercial attachments. If this were at the Sandbox level I probably wouldn't be bringing this up, but the name change along with introduction into Incubation is something new that the CNCF hasn't seen before. I worry people will still colloquially refer to the OSS project as "Ambassador" (and documentation and install scripts still use the name).
Hi Joe, Matt, many thanks for your comments.
@Matt, I remember you raising this in the DD document comments,
and @Chris Aniszczyk suggested this would be acceptable under the
trademark policy (e.g. "X for Envoy"). He suggested that we use a
short name like "IC4E" in the docs and new website that would be
created for the project.
We originally looked to ingress-nginx as inspiration, since the
community seems to have accepted this as a name even though it’s
well-understood it’s not “official”. We also wanted to with a
descriptive name instead of an abstract name, because we thought
it would be easier for people to understand.
Best wishes,
Daniel
On 06/01/2021 19:54, Matt Klein wrote:
> I object to the name "Ingress Controller for
Envoy Proxy” as that also describes Contour. This will create
confusion and will be easily misread as "THE Ingress Controller
for Envoy Proxy" and will violate the "no kingmakers" value of
the TOC.
I agree and I raised a similar concern at some point but I
don't remember the outcome here. @Daniel Bryant?
On Wed, Jan 6, 2021 at 10:48
AM Joe Beda < joe@...> wrote:
What is the new name? The name "ambassador" is
all over the docs and I'd expect to see this reframed around
the new name.
I object to the name "Ingress Controller for Envoy
Proxy” as that also describes Contour. This will create
confusion and will be easily misread as "THE Ingress
Controller for Envoy Proxy" and will violate the "no
kingmakers" value of the TOC.
Joe
All,
Ambassador is applying for incubation status:
DD has been reviewed by myself and SIG Network
and we are supportive. We are now calling for the 2
week public comment period prior to the vote.
Thanks,
Matt
--
Daniel Bryant | @danielbryantuk
--
I like to work flexible hours (and across time zones), but please don't feel obligated to reply to this message outside of your own working hours.
--
--
|
|
Re: Public comment period for Ambassador
Personally I disagree that this is akin to asking for a license change.
The name is an intrinsic part of the project. It is the primary key for the community. This feels more like accepting a fork (well, I'm assuming there is no divergence) while the original project stays with the commercial entity. Personally, I'm interested to see how much of a community is left after the name change and how much of that community is attached to the commercial entity named "Ambassador".
toggle quoted message
Show quoted text
On Thu, Jan 7, 2021 at 10:04 AM Chris Aniszczyk < caniszczyk@...> wrote: I don't think we have to fully pause everything but it's up to the TOC here, if the TOC is saying "choose another name than IC4EP or something else that wouldn't confuse end users" before we accept the project fully then the project can do that in parallel as we onboard it as part of staff duties. We can work with the project to pick up a name and run it by the TOC again.
IMHO I view this a bit similar to a project coming in that may have to change a license to Apache-2 etc (like grpc did as an example), just part of the onboarding process.
OK then IMO we have to pause this for a bit. Can we finalize the name, get it fully done, and then re-submit the DD with the new name, website, etc. clearly in place?
On Thu, Jan 7, 2021 at 9:55 AM Chris Aniszczyk < caniszczyk@...> wrote: The problem is the company rebranded to Ambassador also here: https://www.getambassador.io, so the project needs to be renamed to deal with the obvious trademark conflict here. The CNCF is open to whatever the project decides and that clears a trademark search.
Also, to be clear, I think Ambassador is a big part of the OSS brand and I had erroneously thought that we were sticking with that name. If we are going to change the name to something entirely new it might be good to do that and then circle back in a few months to see how it's going.
I'm sorry for not tracking this more closely, but I agree with Joe on this. I'm not OK with an acronym for something that IMO is too generic. I think you either have to stick with Ambassador or choose an entirely new name.
On Thu, Jan 7, 2021 at 9:37 AM Joe Beda < joe@...> wrote: IC4E only begs the question about what it stands for. It also doesn't set the project up, IMO, for success as the more memorable name will be with the commercial entity and it could stunt the development of the open source project outside of the commercial attachments. If this were at the Sandbox level I probably wouldn't be bringing this up, but the name change along with introduction into Incubation is something new that the CNCF hasn't seen before. I worry people will still colloquially refer to the OSS project as "Ambassador" (and documentation and install scripts still use the name).
Hi Joe, Matt, many thanks for your comments.
@Matt, I remember you raising this in the DD document comments,
and @Chris Aniszczyk suggested this would be acceptable under the
trademark policy (e.g. "X for Envoy"). He suggested that we use a
short name like "IC4E" in the docs and new website that would be
created for the project.
We originally looked to ingress-nginx as inspiration, since the
community seems to have accepted this as a name even though it’s
well-understood it’s not “official”. We also wanted to with a
descriptive name instead of an abstract name, because we thought
it would be easier for people to understand.
Best wishes,
Daniel
On 06/01/2021 19:54, Matt Klein wrote:
> I object to the name "Ingress Controller for
Envoy Proxy” as that also describes Contour. This will create
confusion and will be easily misread as "THE Ingress Controller
for Envoy Proxy" and will violate the "no kingmakers" value of
the TOC.
I agree and I raised a similar concern at some point but I
don't remember the outcome here. @Daniel Bryant?
On Wed, Jan 6, 2021 at 10:48
AM Joe Beda < joe@...> wrote:
What is the new name? The name "ambassador" is
all over the docs and I'd expect to see this reframed around
the new name.
I object to the name "Ingress Controller for Envoy
Proxy” as that also describes Contour. This will create
confusion and will be easily misread as "THE Ingress
Controller for Envoy Proxy" and will violate the "no
kingmakers" value of the TOC.
Joe
All,
Ambassador is applying for incubation status:
DD has been reviewed by myself and SIG Network
and we are supportive. We are now calling for the 2
week public comment period prior to the vote.
Thanks,
Matt
--
Daniel Bryant | @danielbryantuk
--
I like to work flexible hours (and across time zones), but please don't feel obligated to reply to this message outside of your own working hours.
--
--
|
|
Re: Public comment period for Ambassador
> if the TOC is saying "choose another name than IC4EP or something else that wouldn't confuse end users" before we accept the project fully then the project can do that in parallel as we onboard it as part of staff duties.
This is what I'm saying. I can't speak for the rest of the TOC but I won't be voting +1 until we have a clear plan here that feels right to everyone.
toggle quoted message
Show quoted text
On Thu, Jan 7, 2021 at 10:04 AM Chris Aniszczyk < caniszczyk@...> wrote: I don't think we have to fully pause everything but it's up to the TOC here, if the TOC is saying "choose another name than IC4EP or something else that wouldn't confuse end users" before we accept the project fully then the project can do that in parallel as we onboard it as part of staff duties. We can work with the project to pick up a name and run it by the TOC again.
IMHO I view this a bit similar to a project coming in that may have to change a license to Apache-2 etc (like grpc did as an example), just part of the onboarding process.
OK then IMO we have to pause this for a bit. Can we finalize the name, get it fully done, and then re-submit the DD with the new name, website, etc. clearly in place?
On Thu, Jan 7, 2021 at 9:55 AM Chris Aniszczyk < caniszczyk@...> wrote: The problem is the company rebranded to Ambassador also here: https://www.getambassador.io, so the project needs to be renamed to deal with the obvious trademark conflict here. The CNCF is open to whatever the project decides and that clears a trademark search.
Also, to be clear, I think Ambassador is a big part of the OSS brand and I had erroneously thought that we were sticking with that name. If we are going to change the name to something entirely new it might be good to do that and then circle back in a few months to see how it's going.
I'm sorry for not tracking this more closely, but I agree with Joe on this. I'm not OK with an acronym for something that IMO is too generic. I think you either have to stick with Ambassador or choose an entirely new name.
On Thu, Jan 7, 2021 at 9:37 AM Joe Beda < joe@...> wrote: IC4E only begs the question about what it stands for. It also doesn't set the project up, IMO, for success as the more memorable name will be with the commercial entity and it could stunt the development of the open source project outside of the commercial attachments. If this were at the Sandbox level I probably wouldn't be bringing this up, but the name change along with introduction into Incubation is something new that the CNCF hasn't seen before. I worry people will still colloquially refer to the OSS project as "Ambassador" (and documentation and install scripts still use the name).
Hi Joe, Matt, many thanks for your comments.
@Matt, I remember you raising this in the DD document comments,
and @Chris Aniszczyk suggested this would be acceptable under the
trademark policy (e.g. "X for Envoy"). He suggested that we use a
short name like "IC4E" in the docs and new website that would be
created for the project.
We originally looked to ingress-nginx as inspiration, since the
community seems to have accepted this as a name even though it’s
well-understood it’s not “official”. We also wanted to with a
descriptive name instead of an abstract name, because we thought
it would be easier for people to understand.
Best wishes,
Daniel
On 06/01/2021 19:54, Matt Klein wrote:
> I object to the name "Ingress Controller for
Envoy Proxy” as that also describes Contour. This will create
confusion and will be easily misread as "THE Ingress Controller
for Envoy Proxy" and will violate the "no kingmakers" value of
the TOC.
I agree and I raised a similar concern at some point but I
don't remember the outcome here. @Daniel Bryant?
On Wed, Jan 6, 2021 at 10:48
AM Joe Beda < joe@...> wrote:
What is the new name? The name "ambassador" is
all over the docs and I'd expect to see this reframed around
the new name.
I object to the name "Ingress Controller for Envoy
Proxy” as that also describes Contour. This will create
confusion and will be easily misread as "THE Ingress
Controller for Envoy Proxy" and will violate the "no
kingmakers" value of the TOC.
Joe
All,
Ambassador is applying for incubation status:
DD has been reviewed by myself and SIG Network
and we are supportive. We are now calling for the 2
week public comment period prior to the vote.
Thanks,
Matt
--
Daniel Bryant | @danielbryantuk
--
I like to work flexible hours (and across time zones), but please don't feel obligated to reply to this message outside of your own working hours.
--
--
|
|
Re: Public comment period for Ambassador

Chris Aniszczyk
I don't think we have to fully pause everything but it's up to the TOC here, if the TOC is saying "choose another name than IC4EP or something else that wouldn't confuse end users" before we accept the project fully then the project can do that in parallel as we onboard it as part of staff duties. We can work with the project to pick up a name and run it by the TOC again.
IMHO I view this a bit similar to a project coming in that may have to change a license to Apache-2 etc (like grpc did as an example), just part of the onboarding process.
toggle quoted message
Show quoted text
OK then IMO we have to pause this for a bit. Can we finalize the name, get it fully done, and then re-submit the DD with the new name, website, etc. clearly in place?
On Thu, Jan 7, 2021 at 9:55 AM Chris Aniszczyk < caniszczyk@...> wrote: The problem is the company rebranded to Ambassador also here: https://www.getambassador.io, so the project needs to be renamed to deal with the obvious trademark conflict here. The CNCF is open to whatever the project decides and that clears a trademark search.
Also, to be clear, I think Ambassador is a big part of the OSS brand and I had erroneously thought that we were sticking with that name. If we are going to change the name to something entirely new it might be good to do that and then circle back in a few months to see how it's going.
I'm sorry for not tracking this more closely, but I agree with Joe on this. I'm not OK with an acronym for something that IMO is too generic. I think you either have to stick with Ambassador or choose an entirely new name.
On Thu, Jan 7, 2021 at 9:37 AM Joe Beda < joe@...> wrote: IC4E only begs the question about what it stands for. It also doesn't set the project up, IMO, for success as the more memorable name will be with the commercial entity and it could stunt the development of the open source project outside of the commercial attachments. If this were at the Sandbox level I probably wouldn't be bringing this up, but the name change along with introduction into Incubation is something new that the CNCF hasn't seen before. I worry people will still colloquially refer to the OSS project as "Ambassador" (and documentation and install scripts still use the name).
Hi Joe, Matt, many thanks for your comments.
@Matt, I remember you raising this in the DD document comments,
and @Chris Aniszczyk suggested this would be acceptable under the
trademark policy (e.g. "X for Envoy"). He suggested that we use a
short name like "IC4E" in the docs and new website that would be
created for the project.
We originally looked to ingress-nginx as inspiration, since the
community seems to have accepted this as a name even though it’s
well-understood it’s not “official”. We also wanted to with a
descriptive name instead of an abstract name, because we thought
it would be easier for people to understand.
Best wishes,
Daniel
On 06/01/2021 19:54, Matt Klein wrote:
> I object to the name "Ingress Controller for
Envoy Proxy” as that also describes Contour. This will create
confusion and will be easily misread as "THE Ingress Controller
for Envoy Proxy" and will violate the "no kingmakers" value of
the TOC.
I agree and I raised a similar concern at some point but I
don't remember the outcome here. @Daniel Bryant?
On Wed, Jan 6, 2021 at 10:48
AM Joe Beda < joe@...> wrote:
What is the new name? The name "ambassador" is
all over the docs and I'd expect to see this reframed around
the new name.
I object to the name "Ingress Controller for Envoy
Proxy” as that also describes Contour. This will create
confusion and will be easily misread as "THE Ingress
Controller for Envoy Proxy" and will violate the "no
kingmakers" value of the TOC.
Joe
All,
Ambassador is applying for incubation status:
DD has been reviewed by myself and SIG Network
and we are supportive. We are now calling for the 2
week public comment period prior to the vote.
Thanks,
Matt
--
Daniel Bryant | @danielbryantuk
--
I like to work flexible hours (and across time zones), but please don't feel obligated to reply to this message outside of your own working hours.
--
|
|
Re: Public comment period for Ambassador
OK then IMO we have to pause this for a bit. Can we finalize the name, get it fully done, and then re-submit the DD with the new name, website, etc. clearly in place?
toggle quoted message
Show quoted text
On Thu, Jan 7, 2021 at 9:55 AM Chris Aniszczyk < caniszczyk@...> wrote: The problem is the company rebranded to Ambassador also here: https://www.getambassador.io, so the project needs to be renamed to deal with the obvious trademark conflict here. The CNCF is open to whatever the project decides and that clears a trademark search.
Also, to be clear, I think Ambassador is a big part of the OSS brand and I had erroneously thought that we were sticking with that name. If we are going to change the name to something entirely new it might be good to do that and then circle back in a few months to see how it's going.
I'm sorry for not tracking this more closely, but I agree with Joe on this. I'm not OK with an acronym for something that IMO is too generic. I think you either have to stick with Ambassador or choose an entirely new name.
On Thu, Jan 7, 2021 at 9:37 AM Joe Beda < joe@...> wrote: IC4E only begs the question about what it stands for. It also doesn't set the project up, IMO, for success as the more memorable name will be with the commercial entity and it could stunt the development of the open source project outside of the commercial attachments. If this were at the Sandbox level I probably wouldn't be bringing this up, but the name change along with introduction into Incubation is something new that the CNCF hasn't seen before. I worry people will still colloquially refer to the OSS project as "Ambassador" (and documentation and install scripts still use the name).
Hi Joe, Matt, many thanks for your comments.
@Matt, I remember you raising this in the DD document comments,
and @Chris Aniszczyk suggested this would be acceptable under the
trademark policy (e.g. "X for Envoy"). He suggested that we use a
short name like "IC4E" in the docs and new website that would be
created for the project.
We originally looked to ingress-nginx as inspiration, since the
community seems to have accepted this as a name even though it’s
well-understood it’s not “official”. We also wanted to with a
descriptive name instead of an abstract name, because we thought
it would be easier for people to understand.
Best wishes,
Daniel
On 06/01/2021 19:54, Matt Klein wrote:
> I object to the name "Ingress Controller for
Envoy Proxy” as that also describes Contour. This will create
confusion and will be easily misread as "THE Ingress Controller
for Envoy Proxy" and will violate the "no kingmakers" value of
the TOC.
I agree and I raised a similar concern at some point but I
don't remember the outcome here. @Daniel Bryant?
On Wed, Jan 6, 2021 at 10:48
AM Joe Beda < joe@...> wrote:
What is the new name? The name "ambassador" is
all over the docs and I'd expect to see this reframed around
the new name.
I object to the name "Ingress Controller for Envoy
Proxy” as that also describes Contour. This will create
confusion and will be easily misread as "THE Ingress
Controller for Envoy Proxy" and will violate the "no
kingmakers" value of the TOC.
Joe
All,
Ambassador is applying for incubation status:
DD has been reviewed by myself and SIG Network
and we are supportive. We are now calling for the 2
week public comment period prior to the vote.
Thanks,
Matt
--
Daniel Bryant | @danielbryantuk
--
I like to work flexible hours (and across time zones), but please don't feel obligated to reply to this message outside of your own working hours.
--
|
|
Re: Public comment period for Ambassador

Chris Aniszczyk
The problem is the company rebranded to Ambassador also here: https://www.getambassador.io, so the project needs to be renamed to deal with the obvious trademark conflict here. The CNCF is open to whatever the project decides and that clears a trademark search.
toggle quoted message
Show quoted text
Also, to be clear, I think Ambassador is a big part of the OSS brand and I had erroneously thought that we were sticking with that name. If we are going to change the name to something entirely new it might be good to do that and then circle back in a few months to see how it's going.
I'm sorry for not tracking this more closely, but I agree with Joe on this. I'm not OK with an acronym for something that IMO is too generic. I think you either have to stick with Ambassador or choose an entirely new name.
On Thu, Jan 7, 2021 at 9:37 AM Joe Beda < joe@...> wrote: IC4E only begs the question about what it stands for. It also doesn't set the project up, IMO, for success as the more memorable name will be with the commercial entity and it could stunt the development of the open source project outside of the commercial attachments. If this were at the Sandbox level I probably wouldn't be bringing this up, but the name change along with introduction into Incubation is something new that the CNCF hasn't seen before. I worry people will still colloquially refer to the OSS project as "Ambassador" (and documentation and install scripts still use the name).
Hi Joe, Matt, many thanks for your comments.
@Matt, I remember you raising this in the DD document comments,
and @Chris Aniszczyk suggested this would be acceptable under the
trademark policy (e.g. "X for Envoy"). He suggested that we use a
short name like "IC4E" in the docs and new website that would be
created for the project.
We originally looked to ingress-nginx as inspiration, since the
community seems to have accepted this as a name even though it’s
well-understood it’s not “official”. We also wanted to with a
descriptive name instead of an abstract name, because we thought
it would be easier for people to understand.
Best wishes,
Daniel
On 06/01/2021 19:54, Matt Klein wrote:
> I object to the name "Ingress Controller for
Envoy Proxy” as that also describes Contour. This will create
confusion and will be easily misread as "THE Ingress Controller
for Envoy Proxy" and will violate the "no kingmakers" value of
the TOC.
I agree and I raised a similar concern at some point but I
don't remember the outcome here. @Daniel Bryant?
On Wed, Jan 6, 2021 at 10:48
AM Joe Beda < joe@...> wrote:
What is the new name? The name "ambassador" is
all over the docs and I'd expect to see this reframed around
the new name.
I object to the name "Ingress Controller for Envoy
Proxy” as that also describes Contour. This will create
confusion and will be easily misread as "THE Ingress
Controller for Envoy Proxy" and will violate the "no
kingmakers" value of the TOC.
Joe
All,
Ambassador is applying for incubation status:
DD has been reviewed by myself and SIG Network
and we are supportive. We are now calling for the 2
week public comment period prior to the vote.
Thanks,
Matt
--
Daniel Bryant | @danielbryantuk
--
I like to work flexible hours (and across time zones), but please don't feel obligated to reply to this message outside of your own working hours.
|
|
Re: Public comment period for Ambassador
Also, to be clear, I think Ambassador is a big part of the OSS brand and I had erroneously thought that we were sticking with that name. If we are going to change the name to something entirely new it might be good to do that and then circle back in a few months to see how it's going.
toggle quoted message
Show quoted text
I'm sorry for not tracking this more closely, but I agree with Joe on this. I'm not OK with an acronym for something that IMO is too generic. I think you either have to stick with Ambassador or choose an entirely new name.
On Thu, Jan 7, 2021 at 9:37 AM Joe Beda < joe@...> wrote: IC4E only begs the question about what it stands for. It also doesn't set the project up, IMO, for success as the more memorable name will be with the commercial entity and it could stunt the development of the open source project outside of the commercial attachments. If this were at the Sandbox level I probably wouldn't be bringing this up, but the name change along with introduction into Incubation is something new that the CNCF hasn't seen before. I worry people will still colloquially refer to the OSS project as "Ambassador" (and documentation and install scripts still use the name).
Hi Joe, Matt, many thanks for your comments.
@Matt, I remember you raising this in the DD document comments,
and @Chris Aniszczyk suggested this would be acceptable under the
trademark policy (e.g. "X for Envoy"). He suggested that we use a
short name like "IC4E" in the docs and new website that would be
created for the project.
We originally looked to ingress-nginx as inspiration, since the
community seems to have accepted this as a name even though it’s
well-understood it’s not “official”. We also wanted to with a
descriptive name instead of an abstract name, because we thought
it would be easier for people to understand.
Best wishes,
Daniel
On 06/01/2021 19:54, Matt Klein wrote:
> I object to the name "Ingress Controller for
Envoy Proxy” as that also describes Contour. This will create
confusion and will be easily misread as "THE Ingress Controller
for Envoy Proxy" and will violate the "no kingmakers" value of
the TOC.
I agree and I raised a similar concern at some point but I
don't remember the outcome here. @Daniel Bryant?
On Wed, Jan 6, 2021 at 10:48
AM Joe Beda < joe@...> wrote:
What is the new name? The name "ambassador" is
all over the docs and I'd expect to see this reframed around
the new name.
I object to the name "Ingress Controller for Envoy
Proxy” as that also describes Contour. This will create
confusion and will be easily misread as "THE Ingress
Controller for Envoy Proxy" and will violate the "no
kingmakers" value of the TOC.
Joe
All,
Ambassador is applying for incubation status:
DD has been reviewed by myself and SIG Network
and we are supportive. We are now calling for the 2
week public comment period prior to the vote.
Thanks,
Matt
--
Daniel Bryant | @danielbryantuk
--
I like to work flexible hours (and across time zones), but please don't feel obligated to reply to this message outside of your own working hours.
|
|
Re: Public comment period for Ambassador
I'm sorry for not tracking this more closely, but I agree with Joe on this. I'm not OK with an acronym for something that IMO is too generic. I think you either have to stick with Ambassador or choose an entirely new name.
toggle quoted message
Show quoted text
On Thu, Jan 7, 2021 at 9:37 AM Joe Beda < joe@...> wrote: IC4E only begs the question about what it stands for. It also doesn't set the project up, IMO, for success as the more memorable name will be with the commercial entity and it could stunt the development of the open source project outside of the commercial attachments. If this were at the Sandbox level I probably wouldn't be bringing this up, but the name change along with introduction into Incubation is something new that the CNCF hasn't seen before. I worry people will still colloquially refer to the OSS project as "Ambassador" (and documentation and install scripts still use the name).
Hi Joe, Matt, many thanks for your comments.
@Matt, I remember you raising this in the DD document comments,
and @Chris Aniszczyk suggested this would be acceptable under the
trademark policy (e.g. "X for Envoy"). He suggested that we use a
short name like "IC4E" in the docs and new website that would be
created for the project.
We originally looked to ingress-nginx as inspiration, since the
community seems to have accepted this as a name even though it’s
well-understood it’s not “official”. We also wanted to with a
descriptive name instead of an abstract name, because we thought
it would be easier for people to understand.
Best wishes,
Daniel
On 06/01/2021 19:54, Matt Klein wrote:
> I object to the name "Ingress Controller for
Envoy Proxy” as that also describes Contour. This will create
confusion and will be easily misread as "THE Ingress Controller
for Envoy Proxy" and will violate the "no kingmakers" value of
the TOC.
I agree and I raised a similar concern at some point but I
don't remember the outcome here. @Daniel Bryant?
On Wed, Jan 6, 2021 at 10:48
AM Joe Beda < joe@...> wrote:
What is the new name? The name "ambassador" is
all over the docs and I'd expect to see this reframed around
the new name.
I object to the name "Ingress Controller for Envoy
Proxy” as that also describes Contour. This will create
confusion and will be easily misread as "THE Ingress
Controller for Envoy Proxy" and will violate the "no
kingmakers" value of the TOC.
Joe
All,
Ambassador is applying for incubation status:
DD has been reviewed by myself and SIG Network
and we are supportive. We are now calling for the 2
week public comment period prior to the vote.
Thanks,
Matt
--
Daniel Bryant | @danielbryantuk
--
I like to work flexible hours (and across time zones), but please don't feel obligated to reply to this message outside of your own working hours.
|
|
Re: Public comment period for Ambassador
IC4E only begs the question about what it stands for. It also doesn't set the project up, IMO, for success as the more memorable name will be with the commercial entity and it could stunt the development of the open source project outside of the commercial attachments. If this were at the Sandbox level I probably wouldn't be bringing this up, but the name change along with introduction into Incubation is something new that the CNCF hasn't seen before. I worry people will still colloquially refer to the OSS project as "Ambassador" (and documentation and install scripts still use the name).
toggle quoted message
Show quoted text
Hi Joe, Matt, many thanks for your comments.
@Matt, I remember you raising this in the DD document comments,
and @Chris Aniszczyk suggested this would be acceptable under the
trademark policy (e.g. "X for Envoy"). He suggested that we use a
short name like "IC4E" in the docs and new website that would be
created for the project.
We originally looked to ingress-nginx as inspiration, since the
community seems to have accepted this as a name even though it’s
well-understood it’s not “official”. We also wanted to with a
descriptive name instead of an abstract name, because we thought
it would be easier for people to understand.
Best wishes,
Daniel
On 06/01/2021 19:54, Matt Klein wrote:
> I object to the name "Ingress Controller for
Envoy Proxy” as that also describes Contour. This will create
confusion and will be easily misread as "THE Ingress Controller
for Envoy Proxy" and will violate the "no kingmakers" value of
the TOC.
I agree and I raised a similar concern at some point but I
don't remember the outcome here. @Daniel Bryant?
On Wed, Jan 6, 2021 at 10:48
AM Joe Beda < joe@...> wrote:
What is the new name? The name "ambassador" is
all over the docs and I'd expect to see this reframed around
the new name.
I object to the name "Ingress Controller for Envoy
Proxy” as that also describes Contour. This will create
confusion and will be easily misread as "THE Ingress
Controller for Envoy Proxy" and will violate the "no
kingmakers" value of the TOC.
Joe
All,
Ambassador is applying for incubation status:
DD has been reviewed by myself and SIG Network
and we are supportive. We are now calling for the 2
week public comment period prior to the vote.
Thanks,
Matt
--
Daniel Bryant | @danielbryantuk
--
I like to work flexible hours (and across time zones), but please don't feel obligated to reply to this message outside of your own working hours.
|
|