►
From YouTube: 2023-04-05 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
B
Getting
hit
with
storms
over
there,
Daniel
yeah,
I
I,
don't
know
if
it's
made
news
outside
of
the
Michigan
area,
but
we're
supposed
to
be
getting
tornadoes
of
between
ef2
and
five
and
hail
of
two
inches
or
larger
sometime
in
the
next
hour
or
so.
Hopefully,
it
misses.
C
A
B
B
I
don't
have
too
many
things
on
the
agenda
today,
anyways,
so
oh
I
put
three
I
meant
to
put
four
here:
I
don't
have
too
many
things
on
the
agenda:
anyways,
but
yeah
I,
guess
we'll
get
started,
I
released
the
version,
1.11
I'm
sure
at
least
some
of
you
noticed
and
as
well.
The
I
think
0.37
experimental
packages
that
went
with
it.
Whatever
the
version
was
that's
relatively
straightforward.
B
Two
of
the
maintainers,
both
Valentine
and
rauno,
have
moved
themselves
to
Emeritus
status.
They
have
not
been
as
active
on
the
project
recently
and
we're
just
trying
to
you
know
clean
up
the
list
of
maintainers
I'm,
also
going
to
look
at
the
approvers
list
for
similar
reasons,
I'm
looking
to
do
more
automation
around
notifying
particularly
component
owners
in
contrib,
when
issues
and
PRS
are
open
on
their
components.
B
But
in
order
to
do
that,
we
need
to
make
sure
the
list
of
people
who
are
going
to
be
notified
is
people
that
will
actually
respond
to
those
types
of
pings.
B
If
anybody
has
any
questions
about
this
I'm
happy
to
answer
them,
but
I
think
it's
it's
relatively
straightforward.
For
now.
B
Okay,
Mark's
not
here,
but
he
asked
that
I
asked
people
for
reviews
on
this
PR.
It
changes
the
grpc
exporter
so
that
it
uses
statically
generated
Js.
B
The
advantages
of
this
are
the
same
as
they
were
in
the
protobuf
exporters.
The
Proto
files
no
longer
need
to
be
shipped
with
the
exporter
and
JS
is
obviously
understood
by
bundlers.
So
if
you're
using
a
bundled.
B
I
did
pull
up
an
issue
from
last
week.
The
logs
SDK
PR
I
did
start
reviewing
it
and
made
some
minor
comments.
I
have
a
more
in-depth
review
partially
completed,
but
we're
just
right
now
waiting
on
the
author
to
make
changes
to
that
I
just
wanted
to
ask
Martin
if
there's
any
update
here,
what
that
you
knew
of
or
if
the
the
pr
author
is
on
the
call
that
would
be
even
better
Martin's
out
this
week,
yeah
it
looks
like
neither
of
them
are
here.
B
So
just
looking
for
reviews
on
the
logs
SDK
honestly
I'd
like
to
have
it
reviewed
and
merged
and
released
in
time
for
cudco.
That
would
be
ideal,
it's
experimental,
so
it
doesn't
have
to
be
100,
complete
or
perfect
at
this
time,
but
it
is
a
fairly
large
change,
so
it
would
be
nice
to
have
some
eyeballs
on
it.
B
Okay,
I
was
trying
to
yeah,
it
looks
like
you
are
on.
The
call.
I
was
wondering
if
there's
an
issue
on
the
or
an
update
on
the
require
in
the
middle
issue.
Here
I
saw
that
you
did
comment
earlier
late
last
week,
so.
E
I
tried
to
Repro
what
he
was
so
yeah
a
little
bit
of
an
update.
I
tried
to
repurp
what
he
was
saying
so
I.
Could
you
know
verify
when
I
make
the
small
change
that
we
discussed
actually
fixes
something
I
wasn't
able
to
get
there
so
I,
don't
know
if
there's
something
different
from
what
I
had
for
my
build
steps
or
dependencies
or
something
if
I
don't
hear
back
from
him.
E
B
Yeah
I
saw
you
had
a
A
reproduction
repo
I
can
take
a
look
at
this
too
after
the
meeting
see
if
there's
anything,
obviously.
B
E
Sorry
there
was
the
other
require
in
the
middle
one
too,
with
the
the
require
promising
the
thing
where
the
stealth
required
was
trying
to
delete
from
the
required
cache
so
that
you
could
re-import
stuff
so
I'm
still
looking
at
a
fix
for
that.
I
have
an
idea,
but
I'm
working
through
the
require
in
the
middle
test,
Suite
right
now
to
see
if
I
don't
break
other
Behavior.
B
Got
it
okay,
I
appreciate
that,
were
you
able
to
reproduce
that
one
I
I
think
that
one
was
relatively
straightforward:
yeah.
B
That
was
all
I
had
on
the
agenda
today
relatively
short
agenda.
If
anyone
has
anything,
they
want
to
add
go
ahead
and
do
that
while
we
go
through
the
triage,
I
guess.
B
C
B
Layer
trying
to
add
a
Boston
message,
attributes
I,
don't
think
it
should
be
I
think
it's
only
adding
one.
Let's
begin
with
code
owner
here,
though
it's
a
great
example
of
something
that
I
would
love
to
be
automated.
B
B
D
Yeah,
so
tracing
channel
just
landed,
it's
built
on
top
of
the
Diagnostics
Channel
API
and
it's
basically
like
a
lower
level
system
of
doing
tracing
so
like
it.
You
have
like
a
trace
around
like
basically
a
specific
span.
There's
not
like
it
itself
does
not
do
linking
between
spans
or
anything
like
that.
It
just
represents
like
a
single
action,
but
you
can
do
the
linking
on
the
consumer
end
and
like
wire,
that
updates
in
clinical
storage,
okay,
but
yeah
this.
D
This
has
landed
and
we're
gonna
start
like
getting
node
core
producing
events
with
this
and
I'm
going
to
be
working
on
getting
it
into
different
libraries.
B
D
Yeah
yeah,
the
the
intent
of
this
specifically,
is
to
eliminate
that
monkey
patching
aspects,
but
basically
like
I
I
built
this
like
originally.
It
was
part
of
the
datadog
Tracer
and
that
was
kind
of
like
our
testing
ground
for
it
and
basically
the
intent
was
to
separate
the
like
instrumentation
from
the
actual,
like
acting
on
the
data
that
comes
from
the
instrumentation.
D
So
we
split
it
into
this
like
instrumentation
and
plug-in
side,
and
then
the
instrumentations
are
designed
in
a
way
to
like
that
can
just
be
lifted
directly
into
the
libraries
So.
Eventually,
the
intentions
of
like
libraries
themselves
will
just
publish
all
the
data
we
want.
Then
we
won't
need
to
instrument
anything
I
mean,
but
I.
A
D
Think
there
will
actually
ever
be
the
future
where
we
don't
need
any
instrumentation,
because
some
libraries
are
just
not
going
to
do
it,
but
give
us
like
a
good
amount
of
the
way.
That's
like
libraries
just
give
us
what
we
need
and
I
think
it's
much
better
performance
having
the
library
just
pass
the
data
along
rather
than
like
wrapping
closures
around
everything
and
all
that
sort
of
thing.
B
B
Having
node
core
I
assume
by
that
you
mean,
like
the
all
of
the
standard,
Library
modules
like
HTTP,
would
admit
these
events.
Yeah
I
mean
that
provides
like
just
HTTP
besides,
like
80
percent
of
value
already,
so
that's
that's
huge
I
think
the
undichi
instrumentation
is
already
using
the
diagnostic
channel
and
moving
more
in
that
direction
is
definitely
I.
Think
an
advantage
for
everybody,
yeah.
A
D
Yeah
so
that
that'll
be
in
node
20.
B
Just
out
of
curiosity,
since
I
haven't
looked
much
at
this,
would
that
be?
Would
we
write
a
single
instrumentation
that
would
capture
all
of
these
tracing
Channel
events?
Would
you
expect
or
would
you
expect,
still
an
instrumentation
per
module
that
emits
events.
D
D
There's
like
a
start
and
end
sort
of
on,
like
the
synchronous,
part,
async,
starter,
Hastings,
start
and
end
around
the
Callback
and
then
like
an
error
event,
and
just
like
all
of
those
share
like
a
middle
part
of
the
namespace
and
so
like
each
each
separate
module
will
have
this
different
name,
and
so
we
have
to
subscribe
to
like
each
separate
thing
and
so
like
we
can
build
separate
subscribers
that
behave
differently,
depending
on
which
thing
we're
subscribing
to
okay.
D
But
well,
it's
it's
Landing
in
the
20,
it's
like
mostly
starting
is
experimental.
That's
yeah!
D
We
like
we've
been
using,
but
it's
still
the
same
API
and
data
dog
for
the
last
like
a
year,
so
I
don't
really
expect
much
to
change
with
it
and
I'm
gonna
see
about
backboarding
into
18,
but
yeah
like
depending
on
your
support
range
for,
like
your
own
products
like
you
might
not
be
able
to
use
it
right
away,
but
it
it
is
designed
specifically
to
the
basically
tracing
channel
is
a
pattern
over
regular
Diagnostics
channels,
so
like
there's
actual
documentation
on
how
to
just
do
the
same
thing
with
regular
Diagnostics
channels
which,
like
already
have
existed
for
a
while.
D
Now
it's
a
little
more
of
a
manual
process
to
do
that,
but
you
can
so
that
gives
us
kind
of
like
a
transition
period
like
we
can
do
the
manual
process.
If
we
need
to.
A
D
And
feel
free
to
like
Ping
me
on,
like
I'm,
in
like
the
openjs
slack.
If
you
can
pick
me
on
there,
if
you
would
have
any
questions.