►
From YouTube: 2022-06-06 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
Okay,
let's
get
started
all
right
so
starting
for
the
sig
check-in,
we'll
go
through
this
quickly
today,
because
I
think
there's
a
number
of
different
discussion
topics
looks
like
we
have
a
discussion
in
progress
about
the
events
and
logs
api,
but
whether
we
want
those
to
be
separate
or
the
same
thing.
A
A
I'm
curious
for
daniel
or
any
of
the
js
people
here
like
do
we
have
sort
of
like
a
base
expectation
for
what
soon
means
like?
Is
this
the
order
of
like
a
couple
weeks
or
like
two
months
or
something
like
that?
A
couple
weeks,
a
couple
weeks,
awesome
cool
updates
for
python4.net
1.3.0
has
had
its
stable
release
completed
next
release
will
focus
on
logging,
integration,
improvements
and
promote
these
improvements.
A
A
V0
is
already
working
on
a
docker
compose
of
several
small
prs
to
clean
up
the
code.
Wow
we've
made
very
fast
progress
there.
An
announcement
blog
post
is
planned
to
draft
it.
Even
better.
A
First
discussion
topic
is
from
jack.
Is
the
compliance
matrix
up
to
date,
given
all
the
recent
activity
around
metrics
asking
me
we're
asking
maintainers
to
update
the
matrix
to
reflect
their
current
state?
That
is
a
very
good
point,
because
I
doubt
it
has
been
updated
jack
did
you
want
to
talk
about
it
more.
B
A
Okay,
the
next
topic
is
one
that
I
I
added
if
you
went
to
cubecon
you're-
probably
familiar
with
this,
but
we
haven't
actually
had
a
chance
as
a
community
to
formally
sit
down
and
discuss
it.
So
the
the
full
context
is:
we've
we've
not
finished
metrics,
but
it's
well
on
its
way
to
being
finished
right,
like
the
difficult
specification
work
that
took
so
long
is
finished.
The
implementations
for
a
large
set
of
libraries
are
have
reached
their
release.
A
That
also
means
there's
an
opportunity
to
to
sit
down
and
think
about
what
we
want
to
focus
on
in
the
next
year
and
and
beyond,
with
metrics
and
tracing
and,
to
a
lesser
extent,
logs
having
been
the
project's
focus,
starting
from
its
origination
or
in
the
case
of
logs,
within
its,
I
guess.
A
After
just
after
its
first
year,
a
lot
of
that
work
is
is
finished,
and
so,
when
I
was
flying
to
kubecon,
I
jotted
down
like
20
different
ideas
for
things
that
we
could
work
on
as
a
community
and
then
at
the
community
meeting
we
had
a
kubecon,
we
brainstormed
more
and
just
had
a
quick
like
straw
poll
about
which
things
people
were
the
most
interested
in,
and
so
I
think,
there's
value
in
going
over
a
few
of
these
today.
A
Now
that
we
have
the
maintainers
and
sort
of
a
lot
of
our
core
contributors
here
and
just
seeing
are
there
any
things
that
we've
missed
in
this
brainstorm?
Are
there
other
topics
that
we
should
work
on,
that
haven't
been
visited
and
secondly,
amongst
the
maintainers
here,
many
of
whom
were
not
present
at
kubecon?
We
should
also
sort
of
update
or
add
to
the
straw
poll
say
to
show
to
better
understand
what
maintainers
are
actually
interested
in
working
on.
A
The
kubecon
community
meeting
had,
I
think,
maybe
like
five
or
six
maintainers
about
ten
con
like
sort
of
maintainers
and
approvers
there,
so
it
was
mostly
dominated
by
users
of
open
telemetry
and
people.
People
who
use
their
organizations
in
production,
which
is
great
and
their
opinion,
matters
a
ton,
but
I
think
there's
also
value
in
getting
the
opinions
of
the
people
who
actually
spend
you
know
hours
so
many
hours
a
week
actually
contributing
to
the
project
about
what
they
want
to
work
on
and
what
excites
them
so
I'll
I'll.
A
Take
the
next,
probably
15-20,
minutes
and
just
very
quickly
go
through
the
things
that
we'd
already
sort
of
jotted
down
on
the
on
the
roadmap
draft,
and
then
we
can
discuss
these
as
maintainers
and
and
perhaps
have
a
quick
vote
on
on
what
we
think
are
most
interesting.
This
isn't
like
some
binding
vote.
This
isn't
a
top-down
project,
I'm
just.
A
I
think
it's
valuable
for
all
of
us
to
understand
what
people
think
we
should
work
on
in
the
coming
year
and
what
things
are
maybe
less
important
so
I'll
quickly
go
through
these
and
then
in
each
one.
We
can.
We
can
do
a
quick
discussion
and
I'm
going
to
do
it
as
fast
as
I
can
because,
of
course,
we're
already
very
familiar
with
all
the
work
that's
ongoing
and
if
you
want
a
link,
I
pasted
it
into
the
notes
here.
A
So
the
first
project
that
sort
of
is
again
these
are
not
in
any
particular
order,
but
the
project
that
that
came
to
mind
when
you're,
brainstorming
things.
The
roadmap
is
finishing.
Logging
work,
I'm
not
going
to
dive
too
much
into
this,
because
this
one's
been
underway
for
for
almost
two
years
now.
But
this
is
really
continuing.
Logging
support
in
the
in
the
collector
to
capture
logs
from
existing
sources
and
then
longer
term
working
on
a
like
a
higher
performance,
maybe
binary
strongly
typed
logging
transmission
format
as
well.
A
Okay,
the
next
is
one
that
some
people
here
are
also
going
to
be
familiar
if
this
is
client
instrumentation.
So
we've
had
client
instrumentation
support
technically
in
open
telemetry
since
almost
the
very
beginning
in
the
javascript
library,
but
it's
generally
been
underspecified
and
so
there's
already
work.
That's
been
going
on
for
the
last
few
months
to
create
a
client
instrumentation
sig
that
will
specify
the
behavior
of
client
instrumentation,
both
in
javascript
as
well
as
other
languages.
A
Right
so
like
you,
could
imagine
swift
support
for
ios
and
java
support
for
android,
and
I
don't
know
like
c
plus,
plus
and
dot
net
support
for
windows
and
so
on.
So
this
there
is
already
work
ongoing
here,
but
I
imagine-
and
I
suspect
a
number
of
us
imagine
that
this
will
become
a
sort
of
higher
priority,
more
visible
project
than
it
now
than
it
has
been
in
the
past,
and
that's
why
it's
listed
here.
A
But
I
don't
think
it's
had
a
huge
amount
of
visibility.
It
might
be
a
thing
that
we
want
to
invest
further
in.
This
is
the
ability
both
for
the
sdks
and
collector
and
language
agents
and
other
hotel
components
to
report
back
data
about
themselves
to
wherever
they're
exporting
information,
as
well
as
for
some
sort
of
third
party
service,
or
really
anything
to
make
some
configuration
changes
to
these
while
they're
running.
A
The
next
is
profiling.
Profiling
is
one
that
I
think
a
lot
of
people
have
talked
about
in
the
past,
but
we've
never
really
formally
come
together
as
a
community
to
discuss,
adding
it
and
so
effectively.
This
is
adding
a
new
signal
type
to
open,
telemetry,
much
like
how
we
added
logs,
in
addition
to
traces
and
metrics.
A
This
would
be
adding
profiles
effectively
performance
information
about
your
actual
code
and
functions
in
it
captured
from
production
that
would
be
added
to
open
telemetry
correlated
with
all
the
same
resource
metadata
as
everything
else
and
then
submitted
to
backends
for
analysis
again.
A
So
I'm
very
just
interested
in
it
like
just
technically,
but
I
do
think
there's
a
ton
of
value
people
can
extract
and
it
was.
It
was
interesting
to
see
that
so
many
people,
I
guess
in
our
community
of
contributors
and
users,
also
think
that
this
is
very
important.
I
hadn't.
A
So
we
should
talk
about
this
one
a
bit
more
seriously.
If
you
are
interested
in
profiling,
there's
a
there
was
a
meeting
last
week
on
friday
to
to
sort
of
discuss
the
formation
of
a
sig
and
creation
of
a
profiling
project
with
an
hotel.
We
haven't
set
a
recurring
meeting
time
yet,
but
this
will
be
getting
kicked
off.
So
please
it's
on!
There's
a
slack
channel
now
on
on
the
cnc
slack,
if
you're
interested
or
just
reach
out
to
me
and
and
we
can
get
you
involved.
A
A
Next
production
debugging-
this
is
one
that's
far
less
defined.
I
think
it's
less
critical,
it
wasn't
certainly
was
not
near
the
top
for
the
highest
voted
ones,
but
it
was
just
an
idea
for
a
thing
we
could
work
on
as
a
community,
and
so
production
debugging
is,
is
examples
of
this
are
like
being
able
to
dynamically
generate
new
log
statements
in
production
applications
or
to
set
a
sort
of
snapshot,
points
effectively
break
points
that
don't
actually
halt
execution
again
in
production
services.
A
Another
idea
was
capturing
environment
data,
so
this
is
using.
This
was
hastily
typed
in
by
me,
based
on
someone's
comment
at
the
meeting,
but
this
is:
can
we
get
hotel
components
to
capture
environment
variables
or
other
environment
data
as
supported
by
various
preprocessors
today,
so
this
might
be
just
in
enhancing
the
the
metadata
that
we
captured
there's
another
category
of
roadmap,
editions
that
are
more
self-contained,
so
these
are
things
that
are
not
cross-cutting
that
involve
that
require
like
spec
changes
and
thus
implementation
from
various
sigs.
A
These
are
things
that
can
be
done
in
isolation.
The
first
is
in
progress.
We
just
got
an
update
from
it.
That's
that's
the
demo
app,
so
it
is
technically
on
the
roadmap,
but
that's
all
pretty
well
underway,
and
it
looks
like
we're
making
pretty
blistering
progress
there,
which
is
great
another.
That's
in
progress,
though
I
haven't
actually
caught
up
with
in
a
while
is
evpf.
C
A
Next
we'd
also
talked
about
just
sort
of
improvements
to
the
project.
We
can
make
I'm
not
going
to
go
over
these
today,
we'll
actually
leave
them
for
next
week
because
they're
a
little
different
than
the
roadmap,
but
this
is
just
generally
things.
We've
talked
about
before,
but
again
we'll
talk
about
these
in
a
dedicated
discussion
next
week,
because
it's
kind
of
orthogonal
to
the
to
what
we
were
talking
about
today.
A
Okay,
so
we've
finished
up
at
the
kubecon
meeting
with
the
attendees
who
were
there
by
just
voting
on
the
items
that
were
on
this
higher
up
on
this
list,
and
when
we
were
there,
we
told
people
just
to
put
three
x's
down
on
this
whole
column.
They
could
choose
the
xs.
However,
they
wanted
and
just
add
those
and
just
for
a
basic
straw
poll
to
see
what
people
were
interested
in
and
so
logging
took
the
lead,
not
a
surprise.
A
Logging
is
already
both
an
obvious
signal
that
needs
to
be
added
to
open
telemetry,
as
well
as
something
that's
already
in
progress,
but
the
next
highest
by
far
was
profiling,
followed
by
just
improving
our
optimalization
documentation,
etc,
and
we'll
so
again,
we'll
talk
about
this
one
more
next
week,
because
I
think
this
is
a
bit
separate
from
the
others,
but
in
terms
of
of
like
actual
sort
of
technical
projects
and
things
that
require
a
lot
of
engineering.
A
A
E
I'd
like
to
add
stabilizing
semantic
conventions,
excellent
and.
A
E
Yeah
there's
some
good
there's
drive
drivers
and
progress
of
making
http
messaging.
Currently,
there's
no
stable
semantic
conventions.
Http
messaging,
are,
are
being
worked
on,
but
there's
not
really
any.
I
don't
think
there's
any
other
semantic
conventions
that
anybody's
specifically
focused
on
bringing
to
stability.
Okay,.
E
A
Okay,
I
figured
it
was
pretty
comprehensive,
so
I
see
some
edits
here.
I'm
actually
going
to
reject
these,
because
I
want
to
just
keep
the
these
votes
separate
just
because
the
kubecon
vote
is
perhaps
in
some
way
slightly
more
representative
of
users
just
because
we
had
so
many
users
there
compared
to
maintainers,
and
so
I'm
gonna
remove
the
votes
that
people
just
added
here
and
if
you
can
re-add
those
back
to
the
the
new
center
column
that
I
created.
That
would
be
great.
A
And
add
three
x's,
you
can
add
all
three
to
one.
You
go
two
and
one
or
add
three
separate
ones,
and
yes
thank
you
and
make
it.
E
A
E
E
E
Well,
I
would
have
loved
to
see
if
users
that
stabilizing
semantic
inventions
and
releasing
stable
instrumentations
was
important.
A
The
fact
that
it
was
never
mentioned-
and
there
were
a
lot
of
like
legit
like
pretty
heavy
users
of
hotel
there.
The
fact
that
it
was
never
mentioned
makes
me
think
that
it's
either
something
they
had
they're
unaware
of
slash
something
they
haven't
yet
been
burned
by,
maybe
because
they
haven't
churned.
G
E
A
At
this
point,
in
the
adoption
curve,
like
open,
telemetry
has
grown
tremendously,
but
at
the
same
time
the
majority
of
firms
we
see
using.
It
are
more
I'm
trying
to
think
of
the
weight
right
phrase
not
like
with
it,
but
like
it's
early
in
the
adoption
curve,
they
know
that
it's
early
in
the
adoption
curve.
There
perhaps
is
to
austin's
point
more
accepting
that
that
changes
will
occur
because
they
know
that
they're
early
adopters
and
that's
what
that
can
happen.
A
But
their
expectations
that,
like
the
group
of
people
expressed
at
kubecon,
who
are
early
adopters,
might
be
different
than
the
expectations
of
the
people.
We
expect
to
start
using
open
telemetry
in
this
upcoming
year,
so
their
opinion
is
not
necessarily
representative
of
what
needs
what
we
should.
We
should
always
focus
on
the
most.
A
All
right,
I
think
we
got
our
votes
in
okay
cool,
so
the
next
few
weeks,
I'll
clean
this
up
and
I'll
use
this
for
prioritization
both
of
these
columns.
Again,
it's
really
interesting
they're
so
different,
regardless
of
like
the
votes
right
like
this.
Isn't
the
company
no
one's
your
boss
right,
like
like
within
open
telemetry?
C
A
On
people
choosing
to
work
on
them-
and
so
none
of
this
is
like
a
sort
of
formal
roadmap
where
we
can
draw
like
sort
of
super
firm
prioritizations.
A
But
we
can
let
this
guide
us
as
a
community
and
and
certainly
guide
our
our
discussions
with
with
people
who
either
want
to
get
involved
or
or
for
the
leaders
in
the
community.
For
for
the
things
they
want
to
sort
of
promote
and
talk
about
the
most.
Certainly
like,
for
example,
like
I'm
guessing
from
this
group,
we
won't
have
a
huge
number
of
people
who
are
super
interested
in
profiling.
A
But
conveniently
the
other
thing
is,
there
are
a
lot
of
people
who
are
interested
in
profiling,
who
haven't
yet
contributed
to
open
telemetry,
but
are
now
looking
to
contribute.
And
so,
even
though
there
are
some
items
here
that
might
not
be
highly
voted
by
one
group
or
the
other.
I
suspect
a
number
of
these
will
will
occur
within
the
next
year
and
and
be
sort
of
projects
of
renown
that
people
are
working
on.
D
A
D
Because
it
was,
I
think,
something
that
tigran
raised
in
the
profiling.
Kickoff
is
essentially
like,
there's
a
really
good
chance
for
super
green
field
ideas
to
come
into
the
project
where
there's
already
been
established,
conventions
and
say,
like
the
other.
D
So
maybe
there's
just
like
something:
we
should
strategize
around
like
integrating
existing
maintainers
into
these
new
efforts.
Even
if
they're
not.
A
A
And
you're
right,
profiling
is
probably
the
biggest
example
of
that,
but
there
are
certainly
others
right
like
I.
If
ebpf
were
to
garner
a
larger
group
of
people
working
on
it,
there
would
be
the
same
challenges
there
right.
Client
instrumentation
has
has
people
who
I
mean
now
are
working
on
hotel,
but
when
they
started
on
a
few
months
ago,
many
of
them
were
new
to
the
community
and
you're
right.
A
Beyond
I
mean
two
grand
suggestion
for
them
was
like
go,
go,
read
the
spec
and
and
maybe
attend
a
spec
call
beyond
that,
like
tyler
or
others.
Do
you
have
ideas
like
if
we
have
a
large
influx
of
new
developers
to
the
project?
Do
we
have
any
sort
of
bright
thoughts
on
how
to
get
them
more
quickly,
rapidly
integrated
with
everything
that's
going
on
and
how
the
project
works?.
D
I
mean
my
first
thought
is
something
that
we've
done
in
the
past,
where
there's
some
sort
of
technical
committee
sponsorship.
I
think
that
that's
probably
good.
I.
D
Is
to
ensure
that
the
work
is
not
done
in
a
vacuum
like
that's
the
key,
I
don't
know
if
there's
anything
more
specific
around
like
the
details
of
how
that
should
look
or
even.
C
D
People
outside
of
the
technical
committee,
but
I
think,
as
roles
and
responsibilities
of
the
community
are
defined,
it
would
be
the
technical
committee's
responsibility.
I
do
think
that,
like
there
are
more
people
in
the
project
than
the
technical
committee.
A
D
A
I
will
also
be
pretty
involved
in
profiling,
at
least
for
the
first
few
months,
so
I
can
also
try
and
hesitate,
saying
force
but
like
to
promote
that
and
and
and
bring
up
any
other
sort
of
points
of
integration
with
the
project
tyler.
Given
that
you
were
on
the
kickoff,
I
kind
of
assumed
you
plan
to
be
somewhat
involved,
or,
or
certainly
there
were
other
existing
hotel
contributors
who
were
there
as
well,
who
we
could
we
can
all
work
together
to
better
educate
and
integrate
the
new
the
new
arrivals
to
the
project.
D
Yeah,
I
I
I
do
I
but
like
you're
saying
like
ebpf
like,
I
think,
that's
really
cool,
but
I
really
don't
have
the
time
to
dive
in.
D
Yeah
there's
a
lot
of
other
things.
I
think
on
this
list
that
I
think
we
just
want
to
make
sure
that
we
have
people
paying
attention
to
it.
I
guess
is
the
only
thing
I'm
asking
okay,
I
also
don't
mean
that,
like
we
need
to
have
like
some
sort
of
like
authoritative
control
over
it,
like
you're
saying,
like,
I
think,
more
of
a
guiding.
C
D
D
One
of
the
things
that
this
doesn't
actually
capture,
I
think,
is
some
of
the
languages.
Their
signal,
development
of
existing
stabilized
signals
is,
is
still
in
progress,
so
this
is
very
aspirational,
but
it
also
doesn't
like
correct.
I'm
not
too
sure
if
it
like
expresses
that,
like
you
know,
a
new
community
member
comes
in
and
says
like.
These
are
the
things
that
are
gonna
be
worked
on
like
say
in
the
next
quarter
or
two
and
like
I
know
and
go
like.
D
I
don't
think
that's
gonna
happen.
We're
working
on
the
metrics.
A
Understandable
so
let's
add
that
here
so
like
finishing
or
just
expanding
language,
breadth
or
completings
existing
spec.
C
A
Put
a
note
here:
many
sigs
have
great
recording
guides,
but
some
developers
just
want
to
have
the
project
in
the
best
way
possible.
C
D
Okay,
I
would
say:
that's
still
a
really
developer
focused
statement
there
and
I
think
the
project
can
really
benefit
from
contributors
outside
of
developers.
C
A
That's
a
really
good
point
tyler,
because
we're
in
a
I
guess,
a
fortunate
situation
as
a
project
where
we
have
a
lot
of
developers
contributing
their
time.
But
there
are
other
roles
where
we
need
assistance
as
well.
A
A
C
Yeah
hi,
just
a
quick
show
of
virtual
hands.
Is
anyone
on
this
call
planning
to
attend
open,
telemetry
community
day
on
the
20th
of
this
month,
either
in
person
or
virtual?
If
you
actually
who's
going
to
be
there
in
person.
A
I
still
need
to
register,
but
I
will
be
there
virtually
okay,
yeah
registration's,
still
open
right.
It
should
be
20,
bucks,
okay,
great
all
right,
so
decent
attendance,
it's
like
a
week
before
my
wedding.
Otherwise
I
would
go
in
person.
C
C
If
you're
gonna
be
there
in
person
we'll
try
to
organize
like
a
maintainers
kind
of
dinner
or
something
after
the
event,
if
you're
gonna
be
there
virtually,
then
I
look
forward
to
seeing
you
there
virtually.
C
But
yeah
tell
your
friends:
get
people
involved
the
this
is
the
second
one
of
these
we've
done.
The
first
one
was
actually
really
pretty
successful.
I
think
in
kind.
C
Together,
a
ton
of
people
that
are,
you
know,
the
hotel
community
is
very
wide.
This
is,
I
think,
sometimes
it's
easy
to
miss
how
wide
it
is,
but
this
is
a
great
opportunity
to
kind
of
entice
people
to
become
contributors,
also
to
get
feedback
really
focus
feedback
on
whatever
your
sig
is
or
whatever
your
area
of
interest
is
so
just
look
forward
to
seeing
everyone,
either
in
person
or
online
and
we'll
catch
up
in
austin.
In
a
couple
weeks,.
H
I
do
have
one
more
quick
thing
to
say
about
that.
One
of
the
things
that
we
sort
of
had
planned
is
a
sort
of
maintainers
panel,
similar
to
what
we
did
at
kubecon.
Since
everyone
on
this
call
is
a
maintainer.
It's
probably
something
that
those
that
are
planning
on
going
should
know
about
maybe
decide
in
advance
whether
you
would
like
to
join
us
on
the
stage
or
not,
but
certainly
all
maintainers
are
invited
to
do
so.
Yes,.
C
And
if
you're
there
virtually,
then
we
will,
someone
will
read
off
your
someone
on
stage
will
act
as
an
interlocutor
for
you.
H
H
As
far
as
I
know,
yeah,
I
believe
also
lolita,
but
I'm
not
100
sure
and
I'm
certain
about
that.
C
Yeah,
I
don't
know
they
seal
her
in
the
the
spaceship.
C
Cool
yep
and
hey
look
forward
to
more
exciting,
open,
telemetry
community
events.
This
fall
at
kubecon
cloud
nativecon,
north
america,
in
detroit
michigan.