|
Re: [VOTE] OpenTracing Project Proposal
toggle quoted message
Show quoted text
On Mon, Sep 26, 2016 at 8:48 AM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote: The OpenTracing ( http://opentracing.io/) team has iterated on their project proposal to a final one which is ready for voting by TOC members: https://github.com/cncf/toc/pull/15
So please vote! The proposal is also embedded below for your convenience: OpenTracing ProposalName of project: OpenTracing Description: A set of consistent, expressive, vendor-neutral APIs for distributed tracing and context propagation, seeslides for the content we presented to the CNCF TOC. Sponsor / Advisor from TOC: Bryan Cantrill <bryan@...> Unique Identifier: opentracing License: Apache License v2.0 Source control repositories: Ben Sigelman (@bensigelman) Yuri Shkuro (@yurishkuro) see the Contributors section for more information
Infrastructure requirements: CI and potentially CNCF Community Cluster access Release methodology and mechanics: Various across platforms Social media accounts: Twitter: @opentracing Existing sponsorship: Nothing formal; LightStep occasionally spends small amounts of money (hosting events, etc) on behalf of OpenTracing tech talks and so forth. Really very little. The core OpenTracing libraries are facade APIs and thus only bring in dependencies that are needed to describe various function parameters and return values. In some cases there are test harnesses that bring in ubiquitous testing packages. OpenTracing is willing to go through and formally enumerate all of these dependencies, but suffice to say there’s nothing interesting to see and everything is permissively licensed. Statement on alignment with CNCF mission: OpenTracing is an open API standard for distributed tracing in applications and OSS packages. Developers with experience building microservices at scale understand the role and importance of distributed tracing: per-process logging and metric monitoring have their place, but neither can reconstruct the elaborate journeys that transactions take as they propagate across a distributed system. Distributed traces are these journeys. So if distributed tracing is so valuable, why doesn’t everyone do it already? Because tracing instrumentation has been fragmented, syntactically inconsistent, and thus excessively expensive to deploy end-to-end across most cloud-native stacks. Distributed tracing is challenging because the instrumentation must propagate the tracing context both within and between processes. Accomplishing this involves many distinct pieces in a (micro-)service stack. In particular, tracing context must be passed through: Self-contained OSS services (e.g., NGINX, Cassandra, Redis, etc) OSS packages linked into custom services (e.g., grpc, ORMs, etc) Arbitrary application glue and business logic built around the above
And there’s the rub: It is not reasonable to ask all OSS services and all OSS packages and all application-specific code to use a single tracing vendor; yet, if they don’t share a mechanism for trace description and propagation, the causal chain is broken and the traces are truncated, often to the point of uselessness. We need a single, standard mechanism to describe the behavior of our systems. OpenTracing is that single, standard mechanism. Regarding CNCF’s charter mission, OpenTracing is specifically concerned with making loosely-coupled [micro]services easier to manage. As such, it is strongly aligned with CNCF and its goal to “significantly increase the overall agility and maintainability of applications” by “[making] technology ubiquitous and easily available through reliable interfaces.” Indeed, OpenTracing and CNCF as a whole mutually benefit one another. (It should be noted that, as it is focused on standard instrumentation more than standard encoding formats, OpenTracing today is most relevant at the application layer; it has few specific opinions about — or strong dependencies on — the container layer or orchestration systems more generally, though service discovery and high-quality tracing are symbiotic.) Ben Sigelman (bensigelman) LightStep Yuri Shkuro (yurishkuro) Uber Dan Kuebrich (dkuebric) AppNeta Ben Cronin (bcronin) LightStep Priyanka Sharma (pritianka) LightStep Dimitrios Kouzis-Loukas (lookfwd) Bloomberg Mck (michaelsembwever) Apache Ivan Fraixedes (ifraixedes)
Github issue/discussion participation: Rodrigo Fonseca (rfonseca) Brown University Colin Patrick McCabe (cmccabe) Cloudera Cagatay Kavukcuoglu (tinkerware) Base60Labs Benjamin Eberlei (beberlei) Qafoo Władysław Bodzek (wladekb) Bogdan Drutu (bogdandrutu) Google Grayson Koonce (breerly) Uber Marcin Grzejszczak (marcingrzejszczak) Zipkin Fabian Lange (CodingFabian) Instana Paul Caporn (drpacman) BBC
Ben Sigelman (bensigelman) LightStep Tobias Schottdorf (tschottdorf) Cockroach Labs Yuri Shkuro (yurishkuro) Uber Brandon Gonzales (bg451) Student Josh MacDonald (jmacd) Bas van Beek (basvanbeek) Stephen Gutekanst (slimsag) Sourcegraph Richard Scothern (RichardScothern) Docker Tamir Duberstein (tamird) Cockroach Labs Kris Kowal (kriskowal) (I think Uber) Aleksey (IncSW) Kyle Conroy (kyleconroy) Stripe Blake Mizerany (bmizerany) Life360 Sebastián Vera (sebastianvera)
Ben Cronin (bcronin) LightStep Ben Sigelman (bensigelman) LightStep Onwukike Ibe (oike) Uber Alexander Sorokin (syrnick) Yuri Shkuro (yurishkuro) Uber
Yuri Shkuro (yurishkuro) Uber Ben Sigelman (bensigelman) LightStep Brandon Gonzales (bg451) Dan Kuebrich (dkuebric) AppNeta
Ben Sigelman (bensigelman) LightStep Adrian Cole (adriancole) Pivotal / Zipkin Mck (michaelsembwever) Apache / Cassandra Onwukike Ibe (oike) Uber Yuri Shkuro (yurishkuro) Uber Mohamed Ezzat (m-ezzat)
Christian Weiss (cwe1ss) Consultant Daniel Wallin (dawallin) Frontwalker Ben Sigelman (bensigelman)
Josh MacDonald (jmacd) LightStep Dimitrios Kouzis-Loukas (lookfwd) Bloomberg Ben Sigelman (bensigelman) LightStep
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
-- Benjamin Hindman
Founder of Mesosphere and Co-Creator of Apache Mesos
|
|
|
Re: [VOTE] OpenTracing Project Proposal
Solomon Hykes <solomon.hykes@...>
Yes. On Mon, Sep 26, 2016 at 8:48 AM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote: The OpenTracing (http://opentracing.io/) team has iterated on their project
proposal to a final one which is ready for voting by TOC members:
https://github.com/cncf/toc/pull/15
So please vote! The proposal is also embedded below for your convenience:
OpenTracing Proposal
Name of project: OpenTracing
Description: A set of consistent, expressive, vendor-neutral APIs for
distributed tracing and context propagation, seeslides for the content we
presented to the CNCF TOC.
Sponsor / Advisor from TOC: Bryan Cantrill <bryan@...>
Unique Identifier: opentracing
License: Apache License v2.0
Source control repositories:
https://github.com/opentracing
https://github.com/opentracing-contrib
Initial Committers:
Ben Sigelman (@bensigelman)
Yuri Shkuro (@yurishkuro)
see the Contributors section for more information
Infrastructure requirements: CI and potentially CNCF Community Cluster
access
Issue tracker: global -
https://github.com/opentracing/opentracing.github.io/issues and per-platform
issues are raised on the per-platform repository’s issues area
Mailing lists
Active: https://gitter.im/opentracing/public
Placeholder: https://groups.google.com/forum/#!forum/opentracing
Related: https://groups.google.com/forum/#!forum/distributed-tracing
Website: http://opentracing.io
Release methodology and mechanics: Various across platforms
Social media accounts: Twitter: @opentracing
Existing sponsorship: Nothing formal; LightStep occasionally spends small
amounts of money (hosting events, etc) on behalf of OpenTracing tech talks
and so forth.
External Dependencies
Really very little. The core OpenTracing libraries are facade APIs and thus
only bring in dependencies that are needed to describe various function
parameters and return values. In some cases there are test harnesses that
bring in ubiquitous testing packages. OpenTracing is willing to go through
and formally enumerate all of these dependencies, but suffice to say there’s
nothing interesting to see and everything is permissively licensed.
Statement on alignment with CNCF mission:
OpenTracing is an open API standard for distributed tracing in applications
and OSS packages. Developers with experience building microservices at scale
understand the role and importance of distributed tracing: per-process
logging and metric monitoring have their place, but neither can reconstruct
the elaborate journeys that transactions take as they propagate across a
distributed system. Distributed traces are these journeys.
So if distributed tracing is so valuable, why doesn’t everyone do it
already? Because tracing instrumentation has been fragmented, syntactically
inconsistent, and thus excessively expensive to deploy end-to-end across
most cloud-native stacks.
Distributed tracing is challenging because the instrumentation must
propagate the tracing context both within and between processes.
Accomplishing this involves many distinct pieces in a (micro-)service stack.
In particular, tracing context must be passed through:
Self-contained OSS services (e.g., NGINX, Cassandra, Redis, etc)
OSS packages linked into custom services (e.g., grpc, ORMs, etc)
Arbitrary application glue and business logic built around the above
And there’s the rub: It is not reasonable to ask all OSS services and all
OSS packages and all application-specific code to use a single tracing
vendor; yet, if they don’t share a mechanism for trace description and
propagation, the causal chain is broken and the traces are truncated, often
to the point of uselessness. We need a single, standard mechanism to
describe the behavior of our systems. OpenTracing is that single, standard
mechanism.
Regarding CNCF’s charter mission, OpenTracing is specifically concerned with
making loosely-coupled [micro]services easier to manage. As such, it is
strongly aligned with CNCF and its goal to “significantly increase the
overall agility and maintainability of applications” by “[making] technology
ubiquitous and easily available through reliable interfaces.” Indeed,
OpenTracing and CNCF as a whole mutually benefit one another. (It should be
noted that, as it is focused on standard instrumentation more than standard
encoding formats, OpenTracing today is most relevant at the application
layer; it has few specific opinions about — or strong dependencies on — the
container layer or orchestration systems more generally, though service
discovery and high-quality tracing are symbiotic.)
See also: the OpenTracing raison d’être on Medium
Other Contributors:
OpenTracing Semantics Repo (formally the opentracing.github.io docs repo)
Ben Sigelman (bensigelman) LightStep
Yuri Shkuro (yurishkuro) Uber
Dan Kuebrich (dkuebric) AppNeta
Ben Cronin (bcronin) LightStep
Priyanka Sharma (pritianka) LightStep
Dimitrios Kouzis-Loukas (lookfwd) Bloomberg
Mck (michaelsembwever) Apache
Ivan Fraixedes (ifraixedes)
Github issue/discussion participation:
Rodrigo Fonseca (rfonseca) Brown University
Colin Patrick McCabe (cmccabe) Cloudera
Cagatay Kavukcuoglu (tinkerware) Base60Labs
Benjamin Eberlei (beberlei) Qafoo
Władysław Bodzek (wladekb)
Bogdan Drutu (bogdandrutu) Google
Grayson Koonce (breerly) Uber
Marcin Grzejszczak (marcingrzejszczak) Zipkin
Fabian Lange (CodingFabian) Instana
Paul Caporn (drpacman) BBC
https://github.com/opentracing/opentracing-go
Ben Sigelman (bensigelman) LightStep
Tobias Schottdorf (tschottdorf) Cockroach Labs
Yuri Shkuro (yurishkuro) Uber
Brandon Gonzales (bg451) Student
Josh MacDonald (jmacd)
Bas van Beek (basvanbeek)
Stephen Gutekanst (slimsag) Sourcegraph
Richard Scothern (RichardScothern) Docker
Tamir Duberstein (tamird) Cockroach Labs
Kris Kowal (kriskowal) (I think Uber)
Aleksey (IncSW)
Kyle Conroy (kyleconroy) Stripe
Blake Mizerany (bmizerany) Life360
Sebastián Vera (sebastianvera)
https://github.com/opentracing/opentracing-javascript
Ben Cronin (bcronin) LightStep
Ben Sigelman (bensigelman) LightStep
Onwukike Ibe (oike) Uber
Alexander Sorokin (syrnick)
Yuri Shkuro (yurishkuro) Uber
https://github.com/opentracing/opentracing-python
Yuri Shkuro (yurishkuro) Uber
Ben Sigelman (bensigelman) LightStep
Brandon Gonzales (bg451)
Dan Kuebrich (dkuebric) AppNeta
https://github.com/opentracing/opentracing-java
Ben Sigelman (bensigelman) LightStep
Adrian Cole (adriancole) Pivotal / Zipkin
Mck (michaelsembwever) Apache / Cassandra
Onwukike Ibe (oike) Uber
Yuri Shkuro (yurishkuro) Uber
Mohamed Ezzat (m-ezzat)
https://github.com/opentracing/opentracing-csharp
Christian Weiss (cwe1ss) Consultant
Daniel Wallin (dawallin) Frontwalker
Ben Sigelman (bensigelman)
https://github.com/opentracing/opentracing-objc
Ben Sigelman (bensigelman) LightStep
https://github.com/opentracing/opentracing-cpp
Josh MacDonald (jmacd) LightStep
Dimitrios Kouzis-Loukas (lookfwd) Bloomberg
Ben Sigelman (bensigelman) LightStep
--
Chris Aniszczyk (@cra) | +1-512-961-6719
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
|
|
|
Re: [VOTE] OpenTracing Project Proposal
Joseph Jacks <jjacks@...>
|
|
|
Re: [VOTE] OpenTracing Project Proposal
Joseph Jacks <jjacks@...>
|
|
|
Re: CNCF Governance Proposal
Thank you Dan
Sent from my iPhone
On Sep 26, 2016, at 9:17 AM, Dan Kohn < dan@...> wrote:
|
|
|
Re: CNCF Governance Proposal
|
Thanks for the comments. I've incorporated changes based on your feedback to https://docs.google.com/document/d/1l6e-hW7C3S6xJjGn47hUKKxeFBxiamAK7kn5efSryxY/edit#
-- Dan Kohn <mailto: dan@...> Executive Director, Cloud Native Computing Foundation < https://cncf.io/> tel:+1-415-233-1000 
|
|
|
|
Re: [VOTE] OpenTracing Project Proposal
YES On Mon, Sep 26, 2016 at 4:48 PM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote: The OpenTracing (http://opentracing.io/) team has iterated on their project
proposal to a final one which is ready for voting by TOC members:
https://github.com/cncf/toc/pull/15
So please vote! The proposal is also embedded below for your convenience:
OpenTracing Proposal
Name of project: OpenTracing
Description: A set of consistent, expressive, vendor-neutral APIs for
distributed tracing and context propagation, seeslides for the content we
presented to the CNCF TOC.
Sponsor / Advisor from TOC: Bryan Cantrill <bryan@...>
Unique Identifier: opentracing
License: Apache License v2.0
Source control repositories:
https://github.com/opentracing
https://github.com/opentracing-contrib
Initial Committers:
Ben Sigelman (@bensigelman)
Yuri Shkuro (@yurishkuro)
see the Contributors section for more information
Infrastructure requirements: CI and potentially CNCF Community Cluster
access
Issue tracker: global -
https://github.com/opentracing/opentracing.github.io/issues and per-platform
issues are raised on the per-platform repository’s issues area
Mailing lists
Active: https://gitter.im/opentracing/public
Placeholder: https://groups.google.com/forum/#!forum/opentracing
Related: https://groups.google.com/forum/#!forum/distributed-tracing
Website: http://opentracing.io
Release methodology and mechanics: Various across platforms
Social media accounts: Twitter: @opentracing
Existing sponsorship: Nothing formal; LightStep occasionally spends small
amounts of money (hosting events, etc) on behalf of OpenTracing tech talks
and so forth.
External Dependencies
Really very little. The core OpenTracing libraries are facade APIs and thus
only bring in dependencies that are needed to describe various function
parameters and return values. In some cases there are test harnesses that
bring in ubiquitous testing packages. OpenTracing is willing to go through
and formally enumerate all of these dependencies, but suffice to say there’s
nothing interesting to see and everything is permissively licensed.
Statement on alignment with CNCF mission:
OpenTracing is an open API standard for distributed tracing in applications
and OSS packages. Developers with experience building microservices at scale
understand the role and importance of distributed tracing: per-process
logging and metric monitoring have their place, but neither can reconstruct
the elaborate journeys that transactions take as they propagate across a
distributed system. Distributed traces are these journeys.
So if distributed tracing is so valuable, why doesn’t everyone do it
already? Because tracing instrumentation has been fragmented, syntactically
inconsistent, and thus excessively expensive to deploy end-to-end across
most cloud-native stacks.
Distributed tracing is challenging because the instrumentation must
propagate the tracing context both within and between processes.
Accomplishing this involves many distinct pieces in a (micro-)service stack.
In particular, tracing context must be passed through:
Self-contained OSS services (e.g., NGINX, Cassandra, Redis, etc)
OSS packages linked into custom services (e.g., grpc, ORMs, etc)
Arbitrary application glue and business logic built around the above
And there’s the rub: It is not reasonable to ask all OSS services and all
OSS packages and all application-specific code to use a single tracing
vendor; yet, if they don’t share a mechanism for trace description and
propagation, the causal chain is broken and the traces are truncated, often
to the point of uselessness. We need a single, standard mechanism to
describe the behavior of our systems. OpenTracing is that single, standard
mechanism.
Regarding CNCF’s charter mission, OpenTracing is specifically concerned with
making loosely-coupled [micro]services easier to manage. As such, it is
strongly aligned with CNCF and its goal to “significantly increase the
overall agility and maintainability of applications” by “[making] technology
ubiquitous and easily available through reliable interfaces.” Indeed,
OpenTracing and CNCF as a whole mutually benefit one another. (It should be
noted that, as it is focused on standard instrumentation more than standard
encoding formats, OpenTracing today is most relevant at the application
layer; it has few specific opinions about — or strong dependencies on — the
container layer or orchestration systems more generally, though service
discovery and high-quality tracing are symbiotic.)
See also: the OpenTracing raison d’être on Medium
Other Contributors:
OpenTracing Semantics Repo (formally the opentracing.github.io docs repo)
Ben Sigelman (bensigelman) LightStep
Yuri Shkuro (yurishkuro) Uber
Dan Kuebrich (dkuebric) AppNeta
Ben Cronin (bcronin) LightStep
Priyanka Sharma (pritianka) LightStep
Dimitrios Kouzis-Loukas (lookfwd) Bloomberg
Mck (michaelsembwever) Apache
Ivan Fraixedes (ifraixedes)
Github issue/discussion participation:
Rodrigo Fonseca (rfonseca) Brown University
Colin Patrick McCabe (cmccabe) Cloudera
Cagatay Kavukcuoglu (tinkerware) Base60Labs
Benjamin Eberlei (beberlei) Qafoo
Władysław Bodzek (wladekb)
Bogdan Drutu (bogdandrutu) Google
Grayson Koonce (breerly) Uber
Marcin Grzejszczak (marcingrzejszczak) Zipkin
Fabian Lange (CodingFabian) Instana
Paul Caporn (drpacman) BBC
https://github.com/opentracing/opentracing-go
Ben Sigelman (bensigelman) LightStep
Tobias Schottdorf (tschottdorf) Cockroach Labs
Yuri Shkuro (yurishkuro) Uber
Brandon Gonzales (bg451) Student
Josh MacDonald (jmacd)
Bas van Beek (basvanbeek)
Stephen Gutekanst (slimsag) Sourcegraph
Richard Scothern (RichardScothern) Docker
Tamir Duberstein (tamird) Cockroach Labs
Kris Kowal (kriskowal) (I think Uber)
Aleksey (IncSW)
Kyle Conroy (kyleconroy) Stripe
Blake Mizerany (bmizerany) Life360
Sebastián Vera (sebastianvera)
https://github.com/opentracing/opentracing-javascript
Ben Cronin (bcronin) LightStep
Ben Sigelman (bensigelman) LightStep
Onwukike Ibe (oike) Uber
Alexander Sorokin (syrnick)
Yuri Shkuro (yurishkuro) Uber
https://github.com/opentracing/opentracing-python
Yuri Shkuro (yurishkuro) Uber
Ben Sigelman (bensigelman) LightStep
Brandon Gonzales (bg451)
Dan Kuebrich (dkuebric) AppNeta
https://github.com/opentracing/opentracing-java
Ben Sigelman (bensigelman) LightStep
Adrian Cole (adriancole) Pivotal / Zipkin
Mck (michaelsembwever) Apache / Cassandra
Onwukike Ibe (oike) Uber
Yuri Shkuro (yurishkuro) Uber
Mohamed Ezzat (m-ezzat)
https://github.com/opentracing/opentracing-csharp
Christian Weiss (cwe1ss) Consultant
Daniel Wallin (dawallin) Frontwalker
Ben Sigelman (bensigelman)
https://github.com/opentracing/opentracing-objc
Ben Sigelman (bensigelman) LightStep
https://github.com/opentracing/opentracing-cpp
Josh MacDonald (jmacd) LightStep
Dimitrios Kouzis-Loukas (lookfwd) Bloomberg
Ben Sigelman (bensigelman) LightStep
--
Chris Aniszczyk (@cra) | +1-512-961-6719
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
|
|
|
[VOTE] OpenTracing Project Proposal
Chris Aniszczyk
The OpenTracing ( http://opentracing.io/) team has iterated on their project proposal to a final one which is ready for voting by TOC members: https://github.com/cncf/toc/pull/15
So please vote! The proposal is also embedded below for your convenience: OpenTracing ProposalName of project: OpenTracing Description: A set of consistent, expressive, vendor-neutral APIs for distributed tracing and context propagation, seeslides for the content we presented to the CNCF TOC. Sponsor / Advisor from TOC: Bryan Cantrill <bryan@...> Unique Identifier: opentracing License: Apache License v2.0 Source control repositories: Ben Sigelman (@bensigelman) Yuri Shkuro (@yurishkuro) see the Contributors section for more information
Infrastructure requirements: CI and potentially CNCF Community Cluster access Release methodology and mechanics: Various across platforms Social media accounts: Twitter: @opentracing Existing sponsorship: Nothing formal; LightStep occasionally spends small amounts of money (hosting events, etc) on behalf of OpenTracing tech talks and so forth. Really very little. The core OpenTracing libraries are facade APIs and thus only bring in dependencies that are needed to describe various function parameters and return values. In some cases there are test harnesses that bring in ubiquitous testing packages. OpenTracing is willing to go through and formally enumerate all of these dependencies, but suffice to say there’s nothing interesting to see and everything is permissively licensed. Statement on alignment with CNCF mission: OpenTracing is an open API standard for distributed tracing in applications and OSS packages. Developers with experience building microservices at scale understand the role and importance of distributed tracing: per-process logging and metric monitoring have their place, but neither can reconstruct the elaborate journeys that transactions take as they propagate across a distributed system. Distributed traces are these journeys. So if distributed tracing is so valuable, why doesn’t everyone do it already? Because tracing instrumentation has been fragmented, syntactically inconsistent, and thus excessively expensive to deploy end-to-end across most cloud-native stacks. Distributed tracing is challenging because the instrumentation must propagate the tracing context both within and between processes. Accomplishing this involves many distinct pieces in a (micro-)service stack. In particular, tracing context must be passed through: Self-contained OSS services (e.g., NGINX, Cassandra, Redis, etc) OSS packages linked into custom services (e.g., grpc, ORMs, etc) Arbitrary application glue and business logic built around the above
And there’s the rub: It is not reasonable to ask all OSS services and all OSS packages and all application-specific code to use a single tracing vendor; yet, if they don’t share a mechanism for trace description and propagation, the causal chain is broken and the traces are truncated, often to the point of uselessness. We need a single, standard mechanism to describe the behavior of our systems. OpenTracing is that single, standard mechanism. Regarding CNCF’s charter mission, OpenTracing is specifically concerned with making loosely-coupled [micro]services easier to manage. As such, it is strongly aligned with CNCF and its goal to “significantly increase the overall agility and maintainability of applications” by “[making] technology ubiquitous and easily available through reliable interfaces.” Indeed, OpenTracing and CNCF as a whole mutually benefit one another. (It should be noted that, as it is focused on standard instrumentation more than standard encoding formats, OpenTracing today is most relevant at the application layer; it has few specific opinions about — or strong dependencies on — the container layer or orchestration systems more generally, though service discovery and high-quality tracing are symbiotic.) Ben Sigelman (bensigelman) LightStep Yuri Shkuro (yurishkuro) Uber Dan Kuebrich (dkuebric) AppNeta Ben Cronin (bcronin) LightStep Priyanka Sharma (pritianka) LightStep Dimitrios Kouzis-Loukas (lookfwd) Bloomberg Mck (michaelsembwever) Apache Ivan Fraixedes (ifraixedes)
Github issue/discussion participation: Rodrigo Fonseca (rfonseca) Brown University Colin Patrick McCabe (cmccabe) Cloudera Cagatay Kavukcuoglu (tinkerware) Base60Labs Benjamin Eberlei (beberlei) Qafoo Władysław Bodzek (wladekb) Bogdan Drutu (bogdandrutu) Google Grayson Koonce (breerly) Uber Marcin Grzejszczak (marcingrzejszczak) Zipkin Fabian Lange (CodingFabian) Instana Paul Caporn (drpacman) BBC
Ben Sigelman (bensigelman) LightStep Tobias Schottdorf (tschottdorf) Cockroach Labs Yuri Shkuro (yurishkuro) Uber Brandon Gonzales (bg451) Student Josh MacDonald (jmacd) Bas van Beek (basvanbeek) Stephen Gutekanst (slimsag) Sourcegraph Richard Scothern (RichardScothern) Docker Tamir Duberstein (tamird) Cockroach Labs Kris Kowal (kriskowal) (I think Uber) Aleksey (IncSW) Kyle Conroy (kyleconroy) Stripe Blake Mizerany (bmizerany) Life360 Sebastián Vera (sebastianvera)
Ben Cronin (bcronin) LightStep Ben Sigelman (bensigelman) LightStep Onwukike Ibe (oike) Uber Alexander Sorokin (syrnick) Yuri Shkuro (yurishkuro) Uber
Yuri Shkuro (yurishkuro) Uber Ben Sigelman (bensigelman) LightStep Brandon Gonzales (bg451) Dan Kuebrich (dkuebric) AppNeta
Ben Sigelman (bensigelman) LightStep Adrian Cole (adriancole) Pivotal / Zipkin Mck (michaelsembwever) Apache / Cassandra Onwukike Ibe (oike) Uber Yuri Shkuro (yurishkuro) Uber Mohamed Ezzat (m-ezzat)
Christian Weiss (cwe1ss) Consultant Daniel Wallin (dawallin) Frontwalker Ben Sigelman (bensigelman)
Josh MacDonald (jmacd) LightStep Dimitrios Kouzis-Loukas (lookfwd) Bloomberg Ben Sigelman (bensigelman) LightStep
-- Chris Aniszczyk (@cra) | +1-512-961-6719
|
|
|
Reminder: RFC on OpenTracing Project Proposal
Chris Aniszczyk
The OpenTracing.io project proposal is up for review: https://github.com/cncf/toc/pull/15
If there are no major issues I will call for a formal project vote on Monday morning the 26th!
Have a great weekend!
-- Chris Aniszczyk (@cra) | +1-512-961-6719
|
|
|
Re: CNCF Governance Proposal
Thanks, I will incorporate these therein.
On Sep 21, 2016 8:55 PM, "Alexis Richardson" <alexis@...> wrote: Alex
All discussion on this matter was in the doc, so you didn't miss
anything. Please DO feel free to suggest edits in the doc. That
would be great.
alexis
On Thu, Sep 22, 2016 at 12:57 AM, Alex Baretto via cncf-toc
<cncf-toc@...> wrote:
> Hello all,
>
> I've been reviewing the recent Graduation Proposal on behalf of Huawei. I
> have recently joined the TOC meetings so I may have missed some of the
> earlier discussions.
>
> I have the following questions:
> - I wanted some clarity on the styling of the graduation evaluation
> criteria. OSS project possess their idiosyncrasies, and whilst the proposal
> puts forward good ideas to capture these, the terminology may not clarify
> them sufficiently, as under the present proposal.
> - It may be good to consider inclusion of more explicit language regarding
> -- "multiple end users" - we may want to specify whether this is more then
> 2 users or more than 3 users, etc.
> -- "committers from more than one organization..." - we may want to
> specify that this means having committers from more than two organizations
> -- "no longer can be recommended" - do we have detailed criteria in mind
> for non-recommendation? ASF?
> -- "no longer represents best practices in its area" - similarly, do we
> have detailed criteria in mind?
>
> Thank you.
>
> Alexandre Baretto
> axbaretto@...
>
> _______________________________________________
> cncf-toc mailing list
> cncf-toc@...
> https://lists.cncf.io/mailman/listinfo/cncf-toc
>
|
|
|
Re: CNCF Governance Proposal
Alex All discussion on this matter was in the doc, so you didn't miss anything. Please DO feel free to suggest edits in the doc. That would be great. alexis On Thu, Sep 22, 2016 at 12:57 AM, Alex Baretto via cncf-toc <cncf-toc@...> wrote: Hello all,
I've been reviewing the recent Graduation Proposal on behalf of Huawei. I
have recently joined the TOC meetings so I may have missed some of the
earlier discussions.
I have the following questions:
- I wanted some clarity on the styling of the graduation evaluation
criteria. OSS project possess their idiosyncrasies, and whilst the proposal
puts forward good ideas to capture these, the terminology may not clarify
them sufficiently, as under the present proposal.
- It may be good to consider inclusion of more explicit language regarding
-- "multiple end users" - we may want to specify whether this is more then
2 users or more than 3 users, etc.
-- "committers from more than one organization..." - we may want to
specify that this means having committers from more than two organizations
-- "no longer can be recommended" - do we have detailed criteria in mind
for non-recommendation? ASF?
-- "no longer represents best practices in its area" - similarly, do we
have detailed criteria in mind?
Thank you.
Alexandre Baretto
axbaretto@...
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
|
|
|
Hello all,
I've been reviewing the recent Graduation Proposal on behalf of Huawei. I have recently joined the TOC meetings so I may have missed some of the earlier discussions.
I have the following questions: - I wanted some clarity on the styling of the graduation evaluation criteria. OSS project possess their idiosyncrasies, and whilst the proposal puts forward good ideas to capture these, the terminology may not clarify them sufficiently, as under the present proposal. - It may be good to consider inclusion of more explicit language regarding -- "multiple end users" - we may want to specify whether this is more then 2 users or more than 3 users, etc. -- "committers from more than one organization..." - we may want to specify that this means having committers from more than two organizations -- "no longer can be recommended" - do we have detailed criteria in mind for non-recommendation? ASF? -- "no longer represents best practices in its area" - similarly, do we have detailed criteria in mind?
Thank you.
Alexandre Baretto
|
|
|
Re: Kubernetes Code of Conduct
|
|
|
Re: Kubernetes Code of Conduct
Chris Aniszczyk
toggle quoted message
Show quoted text
-- Chris Aniszczyk (@cra) | +1-512-961-6719
|
|
|
Kubernetes Code of Conduct
Sarah Novotny <sarahnovotny@...>
Here's our Code of Conduct.
|
|
|
RFC: OpenTracing Project Proposal for CNCF
Chris Aniszczyk
The OpenTracing ( http://opentracing.io/) project proposal is ready for review here:
The proposal is being sponsored by Bryan Cantrill from the CNCF TOC.
Please make any comments on the proposal and if there are no major issues, I will formally kick off a vote for accepting the project into the CNCF on Monday.
Thanks!
-- Chris Aniszczyk (@cra) | +1-512-961-6719
|
|
|
Jonathan Boulle <jonathan.boulle@...>
I will not be able to attend the call this week. Alexis Richardson via cncf-toc < cncf-toc@...> schrieb am Di., 20. Sep. 2016, 21:13:
|
|
|
|
|
|
Can you give my affiliation as something other than ASF? I am not a formal representative of ASF and they get twitchy re: trademarks. Call me unaffiliated for now. (Also I believe Elissa is now at Google?)
|
|
|
|
|
|
