►
From YouTube: 2023-02-01 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
B
C
B
A
Then
welcome
everybody
and
yeah.
The
first
point
on
the
agenda
that
we
have
today
is
the
bug.
Fix
versions
were
released
for
the
for
the
core
packages
and
the
experimental
packages,
so
the
issue
with
the
grpc
instrumentation
should
not
be
resolved,
which
yeah
was
blocking
the
country
release
yeah.
Anything
more
to
add,
regarding
that,
from
from
any
of
you.
A
D
A
All
right,
thank
you,
then,
moving
on,
we
still
have
parts
of
the
exponential
histogram
PR
that
was
split
up
out
there.
The
first
part
was
merged
already
and
the
other
two
parts
are
still
awaiting
approvers.
So
if
any
of
you
are
interested,
please,
head
on
over
there
Matt
give
us
a
walk
through
in
meeting
in
in
December
and
yeah
I.
A
A
E
E
There
so
I
was
just
wondering
like
there
was
one
question
about
the
name
of
the
class
event:
emitter
I,
don't
think
it's
a
big
deal
personally.
I
think
it
can.
You
know
I
would
I
would
rather
merge
this
now.
So
we
can
continue
with
the
log
SDK
and
the
other
packages,
and
then,
if
you
need
to
rename
it,
we
can
rename
it
all
of
it
later,
because
the
name
is
actually
not
defined
in
the
spec
currently.
E
D
I
would
prefer
it
not
just
because
the
way
that
people
tend
to
import
things,
they
would
Shadow
the
event.
Emitter
name
yeah,
and
it
might
be
just
a
little
bit
annoying
right,
like
you
would
have
to
import
event,
emitter
as
Hotel
event,
emitter
or
something
along
those
lines
in
order
to
like
import
it
without
clobbering.
The
built-in
event
emitter,
so
I
would
probably
prefer
not
to
have
the
exact
same
name
as
a
built-in
global.
E
A
E
D
Yeah,
on
my
in
my
mind,
it
does
not
block
this
PR,
especially
since
we
just
had
a
release
like
yesterday
or
two
days
ago
or
whatever,
there's
plenty
of
time
to
update
the
name
before
we
even
have
a
release.
So
we
may
not
even
need
to
worry
about
it
being
breaking
or
anything
like
that.
Okay,
so
yeah
I
will
rerun
these
tests
and
merge
this.
E
A
F
All
right
so
this
year,
I'm
having
with
this
after
the
new
release,
typescript,
is
throwing
some
issues,
throwing
some
errors
with
the
with
the
implementation
of
the
resource
class.
Since
it
has
some
private
attributes
now
and
I
have
some
compatibility
tests
that
use
the
old
resource
implementation
and
it
started
throwing
some
weird
errors
that
I
haven't
really
encountered
before.
I
spoke
to
to
Amir
about
it
and
they
helped
me
understand
a
bit,
but
we
weren't
sure
what
exactly
would
be
the
right
solution
for
this
yeah.
C
I
can
I
can
add
some
background
on
this.
So
I,
don't
know
if
you
remember
the
issue
we
had
with
the
spend
that
every
time
we
released
a
new
version,
then,
if,
if
we
use
the
two
concrete,
the
glasses
of
spin
from
two
different
versions,
then
typescript
would
not
compile,
and
if
I
remember
correctly,
we
ended
up
understanding
that
we
must
use
an
interface
and
not
the
concrete
class
right,
because
it's
very
easy
for
someone
to
create
a
setup
where
the
SDK
Trace
base
is
the
latest
version.
C
But
something
else
like
a
resource
detector
is
not
the
latest
because
it
hasn't
been
released
or
because
it's
been
the
full
version
and
not
being
updated
and
I
think
that
the
resource
class
is
like.
Currently,
it
has
only
public
properties.
So
we
didn't
see
any
issues,
but
now
we
it's
also
changed
and
also
it's
not.
It
has
a
private
properties,
so
I'm
expecting
it
to
be
a
problem
and
and
I'm
I'm
not
sure.
C
D
I
think
we
could
definitely
well
an
interface
is
definitely
the
right
way
to
go
and
any
function
or
method
that
receives
a
concrete
resource.
Right
now
can
just
receive
the
interface
instead
and
that's
non-breaking,
because
the
resource
concrete
class
implements
the
interface.
So
that
should
not
be
a
problem.
D
The
only
time
it
might
be.
A
problem
is
when
a
function
returns
a
concrete
resource
class,
and
we
change
that
to
be
an
interface.
Anyone
that
depended
on
internals
of
the
resource
class
would
then
be
like
the
internals
would
be
hidden
from
the
compiler,
but
that's
fine,
because
they're
internals
they're,
not
a
part
of
the
contract,
anyways,
so
I
think
that's
non-breaking
to
replace
all
of
our
usage
in
all
of
our
function.
Signatures
to
use
the
interface
instead
of
using
the
concrete
resource
class.
B
F
F
D
B
D
That
should
be
relatively
easy
to
fix
by
just
making
the
basic
Tracer
provider
instead
of
in
the
basic
Tracer
provider
options.
Instead
of
having
a
the
resource
key,
be
a
concrete
resource
class,
it
should
be
the
resource
interface
instead,
which
both
the
new
and
the
old
already
Implement.
So
it's
not
a
problem.
Does
that
make
sense.
C
D
D
B
A
D
F
D
A
D
B
C
So
yes,
so
here
this
one,
so
all
of
our
detectors
were
implementing
a
detector
interface,
and
now
we
have
a
detector
sync
interface,
which
makes
sense,
but
I'm
not
sure.
If
replacing
the
existing
detectors
is
a
breaking
change
or
not
like
I
assume
it.
It
is
possible
that
someone
will
be
broken
by
this
change.
I,
don't
think
it's
very
likely,
but
I
think
it
is
possible,
and
if
it
does
then
should
we
keep
all
the
existing
detectors.
Implementing
the
old
interface
with
the
async
signature.
E
C
C
C
D
I'm
going
to
create
a
milestone
for
2.0
and
start
adding
creating
issues
and
adding
them
to
the
2.0
Milestone.
Just
so
that
we
don't
forget
these
things
as
we
go,
because
I
think
when
we
get
to
the
point
that
we're
actually
releasing
the
next
major
version,
there's
already
a
lot
of
things
that
we
said,
we
want
to
do
for
cleanup
that
I
think
might
get
lost.
C
D
D
Was
gonna
say,
I
can
manually
make
a
release
with
an
alpha
version
so
that
it
won't
get
picked
up
like
we.
We
can
release
with
like
1.10.0,
Alpha
One,
or
something
like
that,
so
that
we
can
actually
release
all
the
packages
and
try
to
update
in
a
couple
of
places.
You
know
encourage
people
to
try
it
before
we
actually
release
the
new
version.
D
A
D
A
A
B
E
B
D
A
C
I
played
with
the
instrumentation
a
bit
lately
and
he
does
like
every
time
he
will
click
or
something
you
have
an
event
on
an
HTML
element.
Then
it
triggers,
but
I
think
the
solution
would
be
to
create
a
simpler
to
to
sample
out.
What's
not
interesting,
I'm,
not
sure
if
the
sampler
has
enough
data
to
make
a
decision,
but
I
think
this
is
the
way
to
Google.
B
D
D
B
D
B
Unlikewise
a
span
would
would
be
tagged
with
the
same
session
ID
as
well.
So
you
could
say
I
want
to
look
at
everything
that
this
user
did
and
you
group
them,
rather
than
having
a
parent
span
having
the
same
crease
idea
across
everything.
That
would
never
get
closed,
which
would
be
the
other
way
to
do
it.
D
B
D
B
D
D
A
D
D
D
On
this
example,
so
I
I
his
example.
Is
he
clicks
one
time
and
sees
four
traces?
It
looks
like
the
last
note.
Is
they
tried
it
in
a
production,
application
and
they're,
seeing
50
to
80
traces,
so
the
example
is
going
to
show
four
traces
where
he
expects
one
and
is
just
like
a
minimal
example
of
what
he's
saying
so
I'd
like
to
see
what
are
the
actual
four
traces
and
are
they
actually
spans
instead
of
traces?
So.