►
From YouTube: 2022-11-30 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
B
C
A
B
C
Great
I
guess
we
can
get
started
here.
Everybody
see
my
screen
or
no.
C
First
thing
I
wanted
to
point
out
here,
which
is
just
kind
of
an
FYI.
There
is
a
PR
open
in
the
specification
now
to
Define
what
clients
can
and
cannot
do
it
is
fairly
restrictive.
C
C
Now
we
already
try
not
to
do
things
that
aren't
in
the
specification,
but
we
do
have,
for
example,
like
the
sugared,
Tracer,
PR
open
right
now
and
some
other
things
that
we
do
deviate
from
the
specification
in
some
places
or
Implement
things
that
are
not
fully
specified
in
some
places.
C
C
All
right
Mark:
do
you
want
to
talk
about
this
next
issue.
E
Yeah
so
last
week,
Aaron
Abbott
joined
and
brought
up
this
issue
about
the
instrument,
the
script,
the
semantics
being
kind
of
unclear
when,
when
using
views,
we
have
this
descriptor
type
on
the
data
point
which
refers
to
the
original
instrument,
which
kind
of
made
it
in
there
by
accident,
so
I'm
proposing
that
we
deprecate
that
one
and
documented
it
basically
refers
to
the
original
instrument
instead
of
what
would
be
the
mapped
instrument
for
the
view,
because
that
is
not
entirely
mappable.
E
So,
for
instance,
if
we
had
an
updown
counter
with
explicit
packet
histogram
aggregation,
we
would
still
have
to
keep
that
that
up
down
counter,
because
normal
histogram
wouldn't
be
able
to
to
accept
negative
values
and
an
up
down
counter
does
so
just
putting
histogram
in
there
wouldn't
wouldn't
be
accurate
enough
so
facing
that
out
would
probably
be,
in
my
opinion,
the
best
solution
just
asking.
If,
if
there's
any
differing
opinions
there
and
yeah,
there's.
E
Right,
yeah,
just
the
type
because
the
other
pieces
in
there,
the
name
and
the
description
they
refer
to
kind
of
a
virtual
instrument
created
by
the
view,
so
the
name
and
the
description
can
be
changed.
But
if
you,
for
example,
or
the
unit-
and
these
are
already
updated,
so
basically
the
whole
everything.
That's
in
the
descriptor
already
refers
to
this
virtual
instrument,
except
for
the
type
and
that
one
is
not
supposed
to
be
in
there.
E
Basically,
that
is
basically
was
missed
before
ga
when
I,
when
I
reviewed
the
the
SDK
for
exports
that
shouldn't
be
there.
That
was
one
of
the
things
that
that
unfortunately
made
it
through.
C
Okay
and
then
we
should
probably
also
add
documentation
in
the
TS
docs
for
this
for
sure
that
that
explicitly
call
out
that
all
of
the
fields
are
for
the
instrument.
Virtually
you
know
that
they
they
may
be
affected
by.
E
Right,
yeah
and
Aaron
I
think
also
suggests
that
renaming
it
renaming
the
type
that
is
instrument
descriptor
to
the
script.
I'm
not
sure
I
would
have
to
see
if
there's
a
way
to
do
that
in
a
non-breaking
manner,
I
would
have
to
prototype
it
a
bit
to
see
yeah.
C
Possible,
it
should
be
possible
to
rename
it
and
then
export
a
Alias,
yeah
deprecated
flag.
The
same
thing
we
did
for
the.
E
For
the
pen
attributes,
yeah
yeah
I
was
thinking
the
same
thing,
we're
still
using
the
span
attributes
everywhere,
though
I
think
that
is
API
related
though,
and
I'm
not
sure.
If
we
might
run
into
the
same
problem
in
case
there's
some
kind
of
exporter
out
there
that
already
uses
it
so
yeah
I
would
have
to
to
to
do
some
prototyping
and
see
if,
if
that
can
be
done,
but
at
least
documenting
it
and
and
deprecating,
this
one
field
would
probably
be
the
best
approach
here.
C
Okay
sounds
good,
I
think
that
sounds
like
a
reasonable
course
of
action.
Anybody
have
comments
or
concerns
about
that.
C
Okay,
next
Point
here
is
me:
I,
don't
have
anything
really
to
share
at
this
point.
I
didn't
have
a
lot
of
time
to
work
on
it
over
the
last
week
because
of
the
holiday,
but
I
am
working
on
rewriting
the
contrib
release,
automation,
the.
C
To
use
release
please
to
bump
the
versions,
because
it
still
does
a
good
job
of
that,
but
then
not
using
it
for
the
actual
release
itself,
because
it
seems
to
fail
every
time.
So,
there's
no
real
point
and
and
trying
to
use
it.
C
Also
brought
over
from
last
week,
the
span
clock
drift.
Pr
I
did
make
an
alternative
PR,
which
is
a
little
bit
simpler
than
the
original
I'm
keeping
them
both
open
for
now,
because
I'm
looking
for
opinions
on
which
people
prefer
I
did
get
a
review
from
T2,
which
I
appreciate
and
I
updated.
C
C
Is
interesting
because
where
am
I
but
I
use
something
yeah?
Okay,
so
your
comment
here,
I
think
that
we
should
update
the
fetch
instrumentation,
but
I
also
think
we
should
update
the
HR
time
method
in
core
to
use
date
dot
now,
instead
of
using
the
performance
timer
most
of
the
time
that
an
instrumentation
would
call
that
method,
they're
just
looking
to
get
the
current
time.
C
Anyways
and
date
is
a
more
accurate
representation
of
the
current
time
and
the
high
resolution
nature
of
it
does
not
matter
as
much,
because
you
know
it's
not
generated
by
the
runtime
or
anything
like
that.
Anyways
I,
don't
know
if
that
makes
sense,
I
feel
like
I'm,
rambling.
B
I
I
think
updating
both
is
definitely
good,
because
yeah
currently
fits
some
beauty.
Schools
say
that
the
using
Js-
oh
yes,
the
timestamps,
aren't
really
accurate
since
there's
always
some
queuing
in
the
native
dirt,
but
also
yeah
definitely
fixing
nature.
Time
is
also
important
because
there
you
will
never
know
who
will
lose
what
API
to
get
time
stamps.
C
Right
honestly,
I
think
that
we
may
want
to
just
completely
deprecate
HR
time
method
from
core,
because
if
we're
trying
to
Discord
discourage
the
performance,
timer
users
should
be
able
to
just
use
date.now
directly
shouldn't
be
a
problem,
but
we
don't
have
to
do
that
in
this
PR
I
think
that's
a
little
bit
of
creep
so
I'll
do
it
later.
C
Okay,
so
I'm
just
looking
for
reviews
on
that,
probably
I
I
prefer
the
3434
the
the
later
one,
which
I
I
think
is
simpler
but,
like
I,
said
I'm
keeping
both
open
for
now.
In
case
people
prefer
the
other
one.
F
C
C
A
lot
of
people
have
had
vacation
the
last
couple
of
weeks.
So
that's
okay.
Did
you
see
there
was
another
PR
which
refactors
the
log
API
in
order
to
make
it
match
in
order
to
make
it
match
Java
a
little
bit
more
closely.
F
C
C
A
good
like
this
is
the
actual
like
usage
in
the
readme
is,
is
a
good
I
think
view
of
what
actually
changed.
C
C
Okay,
does
anyone
else
have
a
topic
that
they
want
to
talk
about
before
we
move
on
to
bug
triage.
C
C
Okay,
I
will
assign
this
one
to
myself
I'm
going
to
leave
the
triage
label
on
there
for
now,
until
I
figure
out
exactly
what's
going
on.
D
But
in
some
use
cases
we
don't
need
to
look
for
the
exporter
in
there
and
fight
we
can
we
just
the
user,
wants
to
start
a
tracer
provider
with
and
Supply
his
own
exporter
that
he
created,
and
in
these
cases
we
like
the
does
an
arrow.
That
is
not
really
an
error
and
we
just
do
things
that
we
don't
need
to
do
so.
D
D
D
D
C
G
B
C
I
will
assign
to
you,
then.
If
you
look
into
it
and
it
turns
out,
you
don't
have
time
just
comment
and
we
can
mark
it
as
up
for
grabs
or,
if
you
have
may
have
permission
to
do,
that.
C
B
C
I
guess
these
are
not
exact
duplicates
so
I'll
keep
them
both
open
for
now.
I
will
mark
this
as
P2.
C
C
C
C
I'm
sure,
as
always
about
this
as
well
I'm,
not
sure
who
wrote
the
fs
instrumentation
does
anyone
know.
C
C
C
All
right,
then,
thank
you,
everybody
for
your
time
and
I
will
talk
to
you
in
about
a
week.