►
From YouTube: 2022-10-19 meeting
Description
Open Telemetry Meeting 1's Personal Meeting Room
A
A
A
B
A
B
B
I
haven't
seen
the
recent
development
which
is
happening
in
the
specs,
but
just
keep
feel
free
to
add
it
here.
I
do
see
duplicated
Jagger,
Jagger,
exporter,
yeah,
that's
something.
B
B
Action
right
now,
we
just
need
to
probably
just
follow
it
up
when
when
we
up
when
open
Telemetry
is
officially
deprecating
it
probably
we
can
remove
it.
Mark
Mark
Mark,
our
exporter,
has
deprecated
and
then
gradually
or
eventually
remove
it.
A
B
B
B
B
B
I
mean
it's
basically,
I
mean
different
tasks
for
both
the
apis
and
the
sdks,
and
probably
we
can
discuss
it
over
if
we
feel
it's
something
needs
to
be
changed
in
this.
The
problem
right
now
is
that,
even
though
logger
have
been,
we
have
a
logs
API,
but
that
logs
API,
as
of
now
does
not
really
say
it
does
not
really
it's
not
an
API
for
an
end
user
or
an
instrumentation
like
it's
an
API
for
an
appendix,
so
it
has
a
very
specific
purpose.
So
what
that
it?
B
What
it
means
is
that
this
API
is
not
an
official
API,
which
we
have
to
give
it
to
the
end
user,
so
we
can
still
keep
using
our
existing
API,
which
we
have
designed.
We
don't
need
to
remove
it
or
we
don't
need
to
duplicate
it.
We
just
need
to
add
add
few
new
methods
which
are
specifically
designed
or
created
in
this
in
the
API
specs
for
the
appenders,
but
yeah.
That's
that's
something
which
is
good.
I
mean
good
to
State.
B
It
specifically
that
this
is
only
for
dependence,
so
no
not
not
not
a
general
purpose,
logging
API
and
why
it
is
not
a
general
purpose.
Logging
API
I
mean
I
I,
presume
that,
because
most
of
the
languages
have
their
own
standard,
logging
API
as
part
of
the
standard
Library,
unlike
C
plus
plus,
so
keeping
that
in
mind,
probably
open
Telemetry,
is
not
giving
a
specification
for
a
general
purpose.
B
So
probably
we
have
to
design
our
own,
which
means
we
can
keep
the
existing
API
intact
and
we
can
add
new
methods
only
for
the
only
for
the
purpose
of
Apple
printer
which,
as
per
the
API
and
then
it
should
be
good
So
based
on
that
I
think
we
created
the
task
and
I
presume
oven
is
going
to
pick
it
up.
Probably,
let's,
let's
wait:
what
are
his
thoughts?
He
was
on
leave
last
week,
so
he
was.
B
B
And
yeah
support,
Dynamic
logging,
I,
don't
think
anything
is
happening
on
this
structure,
start
tracing
inspired
attributes
and
logs.
B
B
If
it's
some
internal
design
changes
between
the
internal
SDK
API,
we
are
still
good,
but
it
should
not
be
public
API
for
SDK
and
API
as
long
as
it
is
not
there.
So
I
think
we
should
be
good
to
move
it.
It's
important
that
there
should
not
be
any
any
stability
issues
in
the
end
to
end
this
I
mean
that
that's
my
thought
on
this,
but
feel
free
to
add
I
mean
if
you
differ
from
that,
so
switch
to.
C
B
Okay,
you're
saying
we'll
keep
with
the
names
you're
saying
we'll,
keep
it
as
a
long
and
short,
and
is
it
a
scene
yeah
in
six.
A
C
So
the
initial
bigger
report
was
about
what,
if
we
later
need
to
do
some
metrics
with
32-bits
and
what
would
be
the
name,
then,
if
we
ever
do
that.
B
B
B
And
I
just
wanted
to
talk
about
like
we
are
discussing
the
these
changes.
I
just
wanted
to
talk
about.
As
of
now
all
this
methods
to
create
the
instrument
we
are
retaining
a
shared
pointer
and
I'm
just
thinking
whether
we
should
really
return
a
shared
pointer
or
you
can
move
it
to
a
unique
pointer
or
it
does
not
matter
performance,
wise
or
the
apis.
B
Do
you
think
that
it
makes
sense
to
return
unique
pointer
the
thought
with
the
shared
point
that
initially
we
kept
it
as
a
sharepointer,
because
we
felt
that
probably
these
instruments
would
be
I
mean
at
least
I
felt
that
this
instrument
we
may
have
to
use
this
instrument
internally
to
map
to
store
it
in
some
context
or
somewhere
so
but
I
think
now,
when
I
see
I,
really
don't
I,
don't
really
to
see
the
need
that
we
have
to
store
this.
The
reference
of
these
instruments
anywhere
internally
in
the
SDK
okay.
B
B
If
it
is
required
for
that,
I
just
need
to
see
once
again
once
again
if
it
is
required,
probably
which
it's
good
good,
to
have
different
ones
for
observable
and
different
one
for
synchronous,
I
mean.
Is
that
also
fine
I
mean?
Do
you
think,
like
keep
unique
pointers
for
the
synchronous
instruments
and
shared
pointers
for
the
observable
instruments?
B
C
B
Okay,
are
you
sure
right
because
you're
already,
this
is
a
bigger
change?
I
mean
I'm.
Okay,
we
want
to
do
that.
Just
take
it.
Yeah
I'll
create
it
and
I'll
assign
it
to
you.
So
if
you
feel
that
it's
taking
lots
of
time,
probably
you
can
just
tell
me
and.
A
A
Yeah
I
I
checked
Java,
JavaScript,
Python
and
Python
and
dotnet.
They
don't
have
two
metric.
B
A
But
in
dotnet
you
could
have
the
same
thing
that
you
this
issue
talks
about
with
the
shared
pointer
and
the
second
average,
the
there's
a
problem
with
that,
then
that's
we
don't
have.
We
just
have
periodic
metric
reader
periodic
chronometric
reader
yeah.
So
that
means,
even
if
we
go
for
the
second
approach,
we
will
be
limited
to
only
one
type
of
reader
and
we
have
to
like
I,
don't
know,
add
more
in
future.
So
I
would
just
add
the
shared
point
with
that.
A
B
B
A
B
Okay,
that
should
be
okay,
I
think
if
at
least
the
but
I'm
just
thinking,
if
it
is.
B
B
B
B
Definitely
we
need
to
fix
this
circular
dependencies
and
remove
the
weak
pointers,
but
I
just
felt
that
it's
good.
If
you
can
move
it
to
post
GA
and
then
we
can
do
it
separately,
any
design
changes
required
for
this.
It
may
not
be
required
to
require
any
SDK
public
SDK
API
changes,
but
I
thought.
What
do
you
use?
When
do
you
suggest?
Because
you
have
done
changes
to
recruiters.
B
Okay,
yeah:
that's
what
I
felt
and
effectively
we
have
to
do
it,
but
let's,
let's
I,
don't
think
it.
This
is
causing
any
stability
issue.
We
already
are
checking
for
the
validity
for
for
the
pointer
if
they
were
valid
and
then
only
we
are
using
it.
So
it's
not
going
to
cause
any
issue
in
terms
of
the
end
to
ends
use
case
and
that's
the
case
and
probably
we
can
move
it
to
post
GA
and
then
you
can
look
into
that.
A
B
Definitely
P1
and
it
would
still
I'll
say
it's
P1,
but
if
we
say
in
terms
of
our
goal
is
that
it's
that
our
ga
I
mean
the
goal
is
basically
for
the
stability
and
no
API
changes,
public
keypad
changes
and
I
think
it
should
be
good
to
move
that
to
post
you
again,
recordable
interface,
not
very
important,
I
think
it
should
be
good.
We
can
move
it
to
propose
ga,
oh
that's,
I
I
just
had
some
idea.
If
we
can,
we
can
so
if
that
can
improve
the
performance.
B
If
we
use
a
recordable
interface
that
will,
let
us
not
do
do
a
matrix
copy
and
then
serialize
it.
We
can
directly
serialize
this
reading
the
variable
interface
but
I
think
we
can.
We
can
look
into
this
afterwards.
B
Getting
started
documentation
for
Matrix,
API
and
SDK
I
do
see.
Documentation,
T
had
has
created
some
initial
set
of
documents
and
we
have
added
the
reference
API
in
sdkp
document
in
the
read
the
talks.
So
at
least
we
have
some
place
right
now,
where
we
have
the
documents
in
place,
both
both
in
read
the
talks
and
also
in
open
Telemetry
dot
imo.
A
And
I
think
there
is
already
like
oystering
Matrix.
A
B
B
B
A
B
B
B
B
B
But
that
said,
I
mean
we
don't
have
at
least
we
have
some
initial
setup
documentation,
which
is
good
enough
for
a
ga.
B
B
So
it
is,
we
already
discussed,
handle
gaps
and
resets.
This
also
does
not
need
any
EPA
changes
and
I
don't
see
it's
very
important.
This.
This
is
more
of
a
scenario
where
we
created
a
counter
and
there
is
a
reset
in
the
counter
because
of
the
server
getting
we
started
or
something
and
the
counters
are
starting
right
from
beginning.
B
So
we
should
be
able
to
somehow
figure
it
figure
that
reset
and
and
update
our
internal
storage,
reset
all
that
all
the
data
in
that
storage
and
so
that
it
should
start
right
from
the
beginning,
I
mean
the
scenarios
of
the
cumulative
or
a
Delta
where
it
should
not
try
to
find
out
accumulative
with
the
internal
data
which
is
stored
in
start
sending
a
wrong
Matrix
data.
B
So
this,
if
we
don't
reset
our
internal
Matrix
storage,
it
will,
it
could
be
sending
a
wrong
set
of
Matrix
letter
so,
but
that
that's
again
more
of
internal
changes
and
I
think
this
is
something
which
we
can
move
to
post
G.
B
Add
monotonicity
property
for
some
aggregation.
I
have
created
a
PR
for
this.
Please
review
review
that
again.
This
is
not
an
API
change,
but.
A
B
B
B
B
I
think
this
issue
is
not
related
to
the
race
condition
somewhere
in
the
SDK.
This
is
mostly
the
way
the
example
code
is
using
the
sbk.
It's
something
to
do
whether
whether
the
instrument
is
still
active
or
maybe
the
Callback
is
somehow
not
valid,
while
during
shutdown
but
I
mean
as
all.
If
you're
okay
can
I
can.
I
can
I
take
a
take
a
look
into
that
into
those
race
conditions.
So
this
this
already
this.
B
B
A
Tca
race
on
a
ritual
table,
yeah.
B
A
A
A
C
Test
would
be
to
to
compile
with
STD
shot
pointers
to
see
if
it
can
be
reproduced
or
not
to
see.
If
that
comes
from
the
pressure
pointer
itself,.
B
B
B
A
B
A
B
Yeah
he
used
after
free
I.
Think
I
was
looking
into
these,
and
this
probably
I
felt
that
this
is
mostly
coming
because
of
the
instrument
not
remaining
valid.
While
we
are
doing
a
shutdown
or
maybe
the
Callback
is
somehow
not
accessible
during
shutdown,
it's
still
trying
to
collect.
While
the
shutdown
is
happening.
B
B
A
B
B
And
you,
you
said
there
are
some
other
race
condition.
Apart
from
what
we
are
seeing
here,
or
this
is
only
one
we
have.
B
A
B
Okay,
I
think
that's
all
we
have,
and
probably
let
me
move
the
one
which
we
are
discussing
to
post
ga
and
then
let's
see
what
are
the
remaining
I
think
the
remaining
would
be
something
the
race
condition
for
this,
which
we
are
seeing
and
switch
to
the
64-bit
integers
and
then
I'll
raise
one
issue
for
changing
shared
pointers
to
Unique
pointers.
B
And,
let's,
let's
see
if
you
if
there
are,
if
there
is
any
other
crash
or
based
condition,
which
we
are
seeing
probably
good
to
raise
it
now
and
let's
take
a
call,
I
still
feel
that
we
should
be
able
to
do
by
October
29th.
We
can
have
it.
The
next
meeting
is
on
24th,
so
we
can
discuss
on
24th
and
probably
take
a
final
call.
If
this
is
the
right
date,.
B
B
A
A
B
B
C
Yes,
so
the
thing
is,
we
have
only
one
semantic
version
for
everything
now
and
yeah
I
think
for
only
one
for
so
raise
a
lot
of
code
and
voice
code
for
traces
for
metrics
and
exporters
and
whatnot.
My
concern
is
that
there
will
always
be
something
that
requires
a
major
change.
For
example,
if
we
duplicate
the
Jaeger
exporter
or
deprecating
is
okay,
but
when,
when
we
remove
it,
this
is
breaking
change.
C
So
if
we
have
only
one
semantic
version,
we
will
be
forced
to
increase
to
version
2
then,
and
then,
if
we
later
discover,
we
have
something
on
metrics
after
GA.
We
also
may
need
to
bump
the
version,
because
of
that.
So
if
we
have
only
one
semantic
version
by
I'm
afraid
that
it
will
always
grow
because
of
one
reason
or
another,
so
I
don't
know
it
how
to
do
it,
but
I
think
we
need
to
have
smaller
space
for
the
a
semantic
version
for
Tracy
is
a
different
one
for
metrics
and
so
on.
C
B
Yeah
this
was
this
was
discussed,
I,
think
long
back
when
the
versioning,
the
policies
was
being
designed
across
different
teams,
and
that
time
we
all
agreed
for
the
C
plus
plus
that,
since
we
are
not
doing
a
different
package
releases
across
different
components,
we
just
have
one
release
for
for
a
source
code
release.
So
we
want
have
a
different
versioning
and
we
won't
do
even
even
we
won't
do
a
any
major
major
version
change
when
a
new
signal
is
added
like
if
a
matrix
is
added.
B
That
does
not
mean
that
we
are
going
to
do
a
major
version.
Change
we'll
announce
it
even
same
thing
for
logs,
but
any
breaking
change
will
do
a
major
version
of
date
expect,
irrespective
of
whether
it's
a
change
in
the
traces
Matrix
or
logs,
okay,
agreed
and
I
think
it
was
with
the
technical
committee.
Also,
they
were
okay
with
that
and.
B
C
B
Mean
it
will
just
complicate
the
thing,
is
we
don't
have?
Unlike
unlike
other
languages,
we
don't
have
separate
packages
for
all
these
components.
We
just
have
one
Source
package,
that's
on
and
so
I
would
know.
I'm.
B
B
Yeah
we
do
have
to
do
it
and
I
think
that's
that's.
We
all
were
okay
at
that
time
that
even
if
it's
it
kind
of
feels
weird
that
we
will
upgrade
it
because
of
Matrix,
but
actually
there
is
no
change
in
the
traces,
locks
or
exporters.
B
So
even
this
single
version
so
which
would
be
the
upgrade,
but
as
long
as
I
think
we
are
documenting
it
or
in
the
release
notes.
It
should
be
fine.
That
God
is
a
breaking
change.
B
B
B
I
didn't
even
get
instrumentation
library
in
scope.
This
is
a
problem
actually
I
think
we
didn't
realize
it
it's.
It's
actually
not
a
breaking
change,
because
this
is
more
of
an
internal
SDK
method.
So,
even
if
we
are
changing
it,
it
should
not
be
affecting
anything
other
than
the
exporters
which
are
using,
which
are
going
to
use
this,
and
the
problem
here
was
that
our
our
unit
tests
are
using
this
get
instrumentation
Library.
They
are
still
testing
the
calling
this
method
for
testing
and
that's
how
it
is
breaking.
B
If,
if
all,
if
the
way
the
build
system,
the
external
build
system
is
treating
all
the
warnings
that
there
is
including
the
application
warnings,
so
that's
how
it
is
causing
a
problem.
So
probably
we
have
to
modify
our
unit
test,
at
least
that
they
should
not
read
this
method.
Wherever
we
are
doing
these
days,
they
should
not
treat
them
as
a
warnings.
C
Well,
we
can
attain
warnings,
but
I'm
really
surprised
that
someone
compelling
with
one
WL
claims
that
it's
a
breaking
change.
It
seems
so
overworked
up
to.
B
Me,
no,
it's
not
a
breaking
change.
I
didn't
really
talk
about
that.
It
definitely
not
a
breaking
change.
It's
any
deprecated
application.
The
application
is
not
breaking
change,
even
in
terms
of
the
major
in
some
work
of
Convention
of
the
city.
It's
not
an
Unicity
as
long
as
we
remove
it,
so
not
a
break
to
change
later,
but
probably
I.
Think
it's
more
that
their
build
is
breaking
because
of
we
did
a
renaming
so
and
the
build
is
breaking
because
they
are,
they
are
building
also
building
the
unit
tests
and
so
okay.
B
So
so
I
think.
Let
me
retrace
it's
it's!
Okay!
It's
a
it's
a
breaking
chain
for
their
build,
not
a
breaking
change
in
terms
of
our
apis
and
the
SDK,
and
it's
a
breaking
chain
for
the
build
because
they
are
also
building
the
unit
test
and
the
unit
tests
are
still
trying
to
test
this
replicated
method,
and
in
that
case
it
will
still
result
in
the
warning
and
I.
B
Don't
know
how
they
are
testing
it,
because
if
how
they
are
building
it,
because
if
they've
built
using
using
our
cmake
I
mean
that's
what
I
was
surprised,
how
they
are
doing
the
build?
Because
if
I
see
the
C
make
list
Maybe.
C
Well,
the
first
thing
is
considering
the
amount
of
warnings
that
got
teamed
up
recently.
I,
don't
see
how
we
could
possibly
build
it
with
running
all
and
running
error
and
before
so
I.
Don't
know
how
that
happened,
but
also
the
thing
is
so.
This
is
a
big
report
about
some
deprecation
warning,
but
since
we
are
building
with
WL,
it
could
be
about
anyone.
B
Okay,
so
it's
it's
so
you're
saying
it
similar
to
what
we
have
to
take
care
of.
If
we
are
using
any
external
components
like
protocol
grpc,
we
have,
we
still
get
those
warnings
and
we
have
to
disable
those
on.
You
know
by
some
means.
Anybody
who
want
to
use
open
television
also
do
something
similar.
A
B
C
Breaks
I
mean
it's,
it's
very
excited.
B
In
this
particular
case,
I
mean
why
my
concern
was
that,
because
this
is
this
is
breaking
because
of
our
build
is
trying
to
use
their
boost.
Deprecated
function,
probably
that
could
have
been
avoided
internally.
B
That
was
something
which
I
felt
but
yeah
if
they
in
general,
if
there
are
any
warnings
and
if
it's
breaking
their
system
because
of
the
warnings
and
I
think
they
have
to,
they
have
to
disable
that
those
warnings,
but
this
specific
case
I
just
felt
it,
because
just
because
that
our
build
System
is
using
to
depreciate
indicated
function
which
can
could
have
been
avoided.
C
B
B
A
B
C
So
this
is
a
case
where,
when
we
beat
we
to
find
package
and
Thrift-
and
it
finds
whatever
is
on
the
machine
and
I
looked
at
that
a
bit
but
I
could
not
even
find
somewhere
where
we
document,
which
version
of
thrift
is
tested
or
recommended,
we
just
say,
use
frifts
and
we,
we
don't
say
which
version
we
test
within
oci,
for
example,
things
like
that.
But
besides
the
the
Jager
exporter
being
deprecated,
it's
probably
cool
that
will
be
removed
in
the
long
term.
B
B
B
That's
a
good
point,
at
least
we
can
we
can.
We
can
start
based
on
our
experience
which
we
are
having
here.
We
can
definitely
document
that
it
does
not
it.
The
build
will
fail
for
say
now.
We
can
it's
practically,
not
possible,
I.
Think
for
us
to
really
test
all
the
versions
but
based
on
based
on
what
the.
A
A
B
A
B
B
10.0.10.2,
so
we
can
always
document
if
we
want
that
those
issues
has
been
seen
while
building
with
this
version.
At
least
we
can
document
specific
to
the
agriculture.
We
can
recommend
that,
but
practically
it's
not
possible
for
us
to
test
for
all
the
versions
and
document
it
somewhere.
So.
B
B
Okay,
I
think:
that's
all
we
have
I,
don't
see
anything
new
created
version
number
14.
This
is
you
already
created
a
PR
right
as
a
market?
Yes,.
B
B
B
B
B
Okay,
yeah
I
think
feel
free,
I,
think
Sr.
If
you
have
can
merge
it
or
I'll
merge
it
afterwards.
B
B
This
is
a
very
generic
comment.
I
think.
If
you
can
have
an
overflow
on
the
some
aggregation
yeah,
you
can
definitely
have
it,
but
I
think
it's.
The
numeric
limit
for
64-bit
is
quite
High,
and
unless,
until
there
is
a
practical
use
case
where
any
of
those
measurements
can
lead
to
that
value,
we
can
look
into
that
and
that's
in
a
in
those
scenarios
as
a
plot
I
think
we
are
good
without
doing
any
validation
for
our
close.
B
System
you
can
do
that
yeah.
You
can
create
an
issue
for
that,
and
probably
we
can
look
into
that.
I
mean
that
if
you
can
can
I
think
probably
probably
people
can
really
comment
on
that.
If
there
is
a
valid
use
case,
they
can
really
comment
on
that.
Instead
of
a
issue
to
fix
the
Overflow
I
think
it
could
be
for
people
to
come
up
with
a
valid
real
world
scenarios
of
the
Overflow.
So
unless
there
are
real
world
scenarios,
we
don't
need
to
fix
it.
B
A
A
B
So
I
have
seen
the
the
recommendation
in
the
specification.
It
does
says
that
overflow
condition
I
think
as
long
as
we
are
large
enough,
not
say
32-bit
or
16
bit,
I
think
we
we
should
be
good
because
probability
of
overflow
is
very
less
and-
and
we
can
rely
on
that
on
the
on
the
backend
system,
to
really
support
it
or
to
detect
it
and
support
it.
So
that
that's
the
recommendation,
which
is
there
for
the
Matrix
photos.
B
B
B
B
We
don't
have
anything
more
to
discuss.
Just
let
me
know
you
can
add
it.
Otherwise
just
wanted
to
call
it
out
that
the
voting
for
The
governance
committee
is
still
open
for
today.
I
think
end
of
PST
today,
not
today,
I
think
by
tomorrow,
Thursday
right
till
20th,
so
probably
yeah.