►
From YouTube: 2022-07-27 meeting
Description
Open Telemetry Meeting 1's Personal Meeting Room
B
C
B
C
C
Okay,
okay,
I
see
mark,
I
will
be
so
specs
update.
I
mean,
I
think
we
I
just
see
out
of
the
major
spec
changes.
I
see
one
of
one
of
one.
One
of
them
is
basically
events
and
log
api
is
kind
of
taking
shape.
I
mean,
I
think
there
is
a
pr
wave
for
them
and
we
don't
have
it
till
now.
We
didn't
have
any
api
for
the
docks.
It
was
only
the
sdk.
C
So
probably
we
need
to
wait
until
it
takes
some
time
for
this
to
get
reviewed
and
finalized,
but
once
it's
done
we
may
have
to
do
something
in
this
in
our
locked
api,
of
course,
we
have
to
add
support
for
emails
and
one
title.
This
will
also
need
something
that
will
log
existing
knowledge.
Here
I
mean
a
quick
look
into
this.
It
looks
like
that.
C
It's
not
okay,
it's
still
adding
it's
having
log
provide
logo,
provider,
logo
and
probably
the
emitter
classes,
but
I
think
it's
somewhat
different
from
what
the
log
sdk
support.
Log
sdk
has
a
logger
emitter,
not
a
logger
provider,
so
there
are
some
some
inconsistency
between
api
and
sdk.
So
probably
we
have
to
wait
for
some
time
before
fine
lines.
C
This
is
still
excuse
me.
This
is
still,
I
think,
the
interview
for
partial
success
for
otlp
exported.
Nothing
has
to
do.
I
don't
think
anything
has
changed
in
other
parts.
Also
this
is
merged.
So
probably
this
support
can
be
added
to
matrix
export
interval
and
export
timeout.
As
of
now
we
do.
We
have
that
in
as
a
configuration
parameter,
whatever
you
can
add
about
environment,
that's
for
periodic
metric
data.
C
For
matrix,
update
yeah,
I
think,
let's
probably
quickly
jump
into
the
current
status.
C
So,
basically,
we
so
this
one
supporting
the
registering
multiple
listing
callbacks
to
one
single
ac
instrument.
I've
raised
a
pr
for
this
feel
free
to
look
into
this.
C
Yeah
this
one
I'll
I'll,
probably
write,
do
have
some
changes
in
the
current
design.
The
way
we
handle
asynchronous
instruments
so
there's
a
few
changes
in
the
current
api
and
the
usdp
I'll
probably
do
a
write-up
of
more
write-up.
What
exactly
has
changed
in
this
and
to
do
some
changes
in
our
design
document
which
we
created
earlier?
That
also
needs
some
changes
because
of
this
I'll
probably
do
that
change
this,
and
I
think
I
think
I
can
put
the
link
here
so
that
it
would
be
easy
for
doing
this.
C
C
So
it's
something
like
like
earlier:
we
were
just
creating
the
the
instrument
or
the
counter,
and
there
was
it
was
not
returning
anything
because
we
don't
need
to,
because
everything
was
once
once
you
have
registered
as
part
of
creating
the
instrument.
We
were
specifying
the
callback.
Also.
This
has
now
changed.
C
C
Apart
from
the
api
thing,
I
I'll
just
document
that
and
then
please
feel
free
to
review
it.
So
I
add
in
memory
yeah
battery
exporter.
I
think
this
pier
was
raised
for
this.
C
A
C
C
C
C
C
C
We
should
just
use
the
internal
data
structure
which
we
use
in
internal
objects,
which
we
use
as
a
proper
matrix,
but
that's
fine,
I
think.
As
long
as
we
can
resolve
this
same
issue,
there
are,
I
think
there
are
other
issues,
also
not
just
this.
C
If
we
see
here
for
4.8,
it
is
failing.
Somehow
4.88
is
not
happy
with
the
raw
strings,
it
is
not
supporting.
I
think
it's
using
some
raw
strings
in
the
voltage
and
some
of
the
gcc
port.
It
is
not
supporting
that.
C
C
C
Excuse
me,
okay
and
add
configuration
options
for
aggregation.
This
I
think,
asan.
You
have
already
raised
a
pr
right.
C
C
C
C
C
C
C
B
C
C
C
C
C
B
B
B
I
think
maybe
yeah,
then
I
think
we
should
do
like
monthly
release
this
week.
Yeah
yeah.
B
B
C
B
C
B
A
There
are
also
some
the
factory
builders
in
the
sdk
for
trace,
so.
C
A
C
A
C
C
C
B
B
C
C
I
know
some
of
the
six
are
maintaining
different
versions
for
each
it's
because
they
they
deliver
the
packages,
not
the
source
code,
so
they
have
different
package
versions
for
each
of
those
for
matrix.
They
have
different
versions
going
on,
for
the
place
is
a
lot
different,
but
let's
see
in
general
how
they
are
what
they
are
following.
B
Sure
I
think
for
this
one,
for
today
I
can
create
the
pr
and
for
one
1.5.
A
By
the
way,
I
have
a
question
in
general
on
the
version
number,
I
know
that
we
use
cementing
versioning,
but
the
question
is
whether
this
version
number
is
for
everything
at
once,
so
the
api
of
sdk,
all
the
exporters
or,
if
we
or
if
we
should
have
some
version
number
for
api,
separate
from
the
version
number
from
the
sdk.
A
What
I'm
getting
at
is
suppose
that
at
some
point
we
make
an
incompatible
change
in
the
sdk.
Only
if
we
do
that,
we
would
have
to
jump
to
a
version
two
of
open
telemetry
and
that
would
indicate
to
people
that
everybody
was
instrumented
their
code
to
do
through
the
instrument
again
at
least
built
again,
even
though
it's
so
changed
in
the
sdk.
Only.
B
C
C
C
Any
change
known
as
exporter
will
result
in
version
update
of
the
entire
package,
even
though
there
is
no
change
in
api,
sdp
and
other
exporters.
So
as
of
now,
we
maintain
single
version
totally
agree
with
you
like.
That,
does
not
really
specifies
what
exactly
is
changed,
even
if
we
are
doing
minor
version
upgrade
and
not
click
clarified,
whether
it's
change
in
the
api
only
or
the
sdp
or
both
or
how
it
qualifies,
but
probably
that's
how
we
have.
C
We
need
to
specify
it
in
release,
definitions
or
release
descriptions,
but
we
don't
follow
different
versions.
As
of
now
I-
and
I'm
just
thinking
this
so
so
when
you're
saying
different
version,
do
you
think
that
we
should
have
different
source
versions,
so
different
archives,
you're
saying
in
terms
of
for
different,
multiple
releases
for
different
for
api.
A
Maintained
so
not
different
archives,
but
communicate
that
this
release
of
open
telemetry
is
for
api
version,
vs
and
sdk
versions.
Vat,
especially
the
the
way
the
api
works.
It's
header
only
and
there
is
a
macro
that
expands
in
the
name,
space
to
open,
telemetry,
v1
and
proceed
and
presumably
later,
to
open
telemetry
v2.
A
But
if
we,
if
we
change
the
sdk
that
cause
the
version
number
to
go
to
two
all
the
code
compiled
against
the
api
version,
one
something
will
be
obsolete.
C
C
But
I
mean
it's
not
just
api
and
sdk.
It's
like
index
port.
I
think
we
have
to
do
that.
We
have
to
basically
do
for
all.
The
exporters
also
maintain
this
separate
version
for
all
the
exporters,
api
hdking
and
then
ensure
that
only
those
versions
which
are
implemented,
but
I
think
we
took
a
decision
that
let's
have
only
single
version
for
all
of
them,
because
it's
a
support
release.
It's
not
the
different
packages.
C
C
B
Yeah,
if
there's
like,
if
there
is
api,
where
you
can
change-
and
I
think
maybe
we
should
increase
our
major
version.
C
B
And
this
is
a
good
question
and
think
about
like
for
the
matrix
rc
release
from
our
release.
Number
like
there's
no
way
to
imply
this
is
for
matrix,
rs
and
rc
red
even
for
semantic
versioning.
It
supports
the
putting
rc
in
the
version
number,
but
we
can't
do
that
for
for
the
matrix
rc.
B
C
C
C
B
A
So
if,
for
whatever
reason,
we
have
to
change
the
major
version
number
because
of
the
sdk
change,
that
version
number
changed
to
two
and
all
the
code
which
is
compiled
against
that
header
file
will
not
link
with
sdk
because
it
will
be
looking
for
version.
One.
A
B
B
I
think
if
there's
no
abi
breaking
change
or
api
breaking
change,
we
shouldn't
like
we
should
not
increase
our
major
version
even
for
any
number
of
sdk
change.
We
should
like
keep
keep
the
current
image
version
one
unless
it
breaks
all
client
compilation.
A
But
imagine
someone
who
is
configuring,
the
sdk
and
making
calls
to
sdk
to
say
I
want
this
exporter
on
that
thing.
If
there
is
a
breaking
change
there,
we
should
have
a
way
to
convey
that
also.
C
So
but
we
are
yeah
but
but
communicating
through
and
this
just
again
correct
me,
I
mean,
if
I'm
understanding
it
right,
we're
communicating
through
the
release
is
not
a
right
way
of
doing
it.
If
any
breaking
change,
we
already
communicated
to
release
the
release
description
when
we
are
mentioning
it
there
do
you
want
at
the
core
level
that
it
should
not
be.
A
C
Yeah
so
as
of
now,
we
communicated
to
released
description
just
just
to
clarify
on
these
three
okay.
No,
not
this
one.
I
think
this
is
abi,
but
probably
just
to
clarify
on
the
version.
The
way
we
maintain.
C
This
level
I
mean
this
is
this
is
the
patch.
This
is,
if
any
any
new
feature,
any
breaking
change
happening
in
the
sdk
or
even
for
the
api,
and
when
the
versioning
discussion
was
happening,
the
the
one
was
basically
specified
for
the
for
the
specification
like
it's,
it
should
match
the
specification.
So
if
we
go
to
the
get
up,
specs.
C
They
always
follow
one.
So
this
basically
one
as
long
as
specification
is
having
the
major
version
as
one
we.
We
agreed
that
we
we
want
to
change
our
v
major
version
to
two
here,
so
as
as,
as
the
open
specs
becomes
v
two
probably
once
we
get
compliant
to
v
two,
we
will
make
this
v
two.
This
would
be
any
breaking
change
at
api,
sdk
level
or
any
new
bigger
feature
which
is
getting
implemented,
and
this
part
more
of
a
smaller
releases
and
in
terms
of
any
breaking
change
specific
to
apa
sdk.
B
Can
we
go
back
to
the
header
file
the
version
dot
edge
under
api
yeah,
I'm
here
here?
This
is
abi
version
and
also
open
telemetry
version
right
both
has
one
I'm
not
not
sure
the
one
should
be
the
consistent
and
the
same
like
we
keep
the
abr
version
as
one
but
open
telemetry
version.
That's
two
four
into
zero.
I
think
that's
also
doable
right.
C
B
So
we
I'm
wondering,
is
it
doable
like
for
the
api
version
to
keep
it
as
one?
If
I
think,
there's
no
breaking
change
or
no
api,
we
can
change,
keep
it
as
one,
but
for
the
second
one
open,
telemetry
version
just
like
follow
the
spec
one
either
it
can
be
two
right.
2.0.
C
Okay,
so
this
this
is
this,
is
we
always
have
it
one
right?
I
mean
we
changed
it,
the
very
first
time
when
we
made
a
ga
for
ga
for
traces
yeah,
it
was
zero
and
then
we
made
it
one
and
we
have
not
changed
it
after
that,
as
we,
we
didn't
see
any
abi
breaking
change
till
now,.
B
A
B
C
But
I
think
avi
change
to
me
will
only
come
mostly
if
there
is
any
api
level
change
coming
in
traces
which
not
just
affects
the
api,
but
also
effects
so
adding
adding
adding
new
attribute
in
say,
get
tracer
or
something.
If
we
add
a
new
new
argument
there,
that
that
will
be
a
api
breaking
change
and
that
will
make
us
to
increment
the
the
version
2
here.
B
C
Yeah,
so
it's
as
now
as
of
now,
it's
only
one
version
and
I
think
that's
what
probably
continue
unless
until
you
we
feel.
We
all
agree
that
we
should
have
separate
version
for
all
all
the
components
which
we
have
and
probably,
if
I
mean
not
something
which
is
which
we
should
cannot,
and
we
should
not
change,
I
think,
feel
free
if
you
feel
there
is
a
better
way
of
doing
it.
C
Marketing
feel
free
to
update
this,
and
I
think
we
all
can
discuss
and
we
all
can
discuss
under
the
pr
and
something
agree
on
or
how
should
we
do
it?
I
mean
there's
not
there's
no
hard
impossible,
that
we
should
have
only
one
volume,
so
it's
just
got
agreed,
I
think
initially
and
we
have
been
just
following
it
so
better
ways
of
doing
it.
I
think,
if
you
want
to
do,
we
really
want
to
agree
on
doing
separate
versions
on
api
sdk
to
get
more
clarity
for
developers.
I
think
definitely
we
can
do
that.
Also.
C
A
Today
we
have
a
lot
of
feature
flags
and
and
code,
which
is
not
ga
yet
so
we
don't
have
so
much
trouble
with
that.
But
later,
when
matrix
rj,
for
example,
we,
the
question
may
come.
C
Yeah,
I
think
once
we
remove
the
feature
flag,
I
think
definitely
under
the
umbrella
of
picture
flags.
We
have
been
doing
lots
of
api
and
sdk
changes
without
worrying
about
the
version,
but
I
think
agree
once
once
we
remove
this
feature
flag,
any
change
which
we
are
doing
at
api
or
sdk
level.
We
need
to
be
posted
and
probably
we
need
to
have.
C
Yeah
but
but
good
discussion,
I
think
definitely,
I
think
something
something
which
we
definitely
should
touch
this
again
once
matrix
and
logs
are
these
are
more
stable
in
those
plants.
B
C
C
A
C
A
Is
reported
for
the
api
for
which,
because
the
api
is
only,
we
don't
have
a
cc
file
to
put
the
single
turn
on
so
I
started
to
write
a
big
comment
about
that
and
I
would
post
it
later,
but
basically
there
are
mostly
two
possible
ways
out
of
that.
One
is
to
try
to
make
ad-only
out
of
it.
Only
single
total
work
and
the
solutions
are.
I'm
not
I'm
not
too
sure
about
the
solution,
but
it
seems
to
be
it
works
in
general
if
the
symbols
are
exported
by
default.
A
Add
some
some
compiling
directives
to
say:
oh,
this
symbol
must
be
exported,
that
symbol
must
be
exported
and
so
on,
so
that
it
finally
works.
C
A
So
maybe
it
can
work
in
general,
but
we
may
find
that
some
old
compiler
doesn't
work
for
that
case,
which
one
raises
the
question:
if
we
want
to
still
support
that
compiler
or
not,
and
so
this
is
one
way
to
basically
try
to
make
it
make
it
only
singleton
work,
no
matter
what
and
the
other
way
is
to
abandon
either
only
singleton
and
have
a
library
for
that.
A
But
that
would
be
an
api
library
which
has
over
consequences,
because
then
people
linking
instrumented
code
will
need
to
link
the
open,
telemetry
api
library
on
top
of
that,
and
that
also
will
cause
some
problem
for
other
people.
So
it's
it's
a
trade-off
basically
of
different
different
things.
B
C
So
so,
as
I
understand,
there
are
two
ways
of
fixing
it.
One
is
to
keep
it
headed
only
and
probably
and
add
these
tags,
these
annotations
for
the
for
those
for
those
methods,
yeah
on
a
single
time,
at
least
yeah
or
otherwise,
move
it
to
the
make
it
as
a
I
mean,
move
them
to
the
source
code
for
source
files.
Yes,
but
I
mean
I
just
I
just
cons,
I
was
just
thinking
whether
will
it
work.
If
we
keep
it
headed.
Only
just
add
these
annotations
for
the
singleton.
C
Because
I'm
just
concerned
about
the
first
option,
because
I
think
owen-
and
these
these
guys
already
tried
owen
and
this
yeah-
these
guys
already
tried
that
approach
and
they
had
they
first
started
with
the
header,
only
approach.
C
C
This
has
both
api.
C
C
Yes,
this
is
this,
is
this
is
a
sample
implementation
which
I'm
seeing
here
so
this
this
guy
has
already
done
some
some
work
on
on
this
approach
to
make
to
support
dll.
So
this
is
a
branch.
This
is
the
private
branch
of
this
person,
this
guy.
So
I'm
just
opening
this
branch,
so
this
branch
has
those
changes.
If
we
go
to
api,
so
he
has
done
kind
kind
of
a
weird
way
with
in
the
in
the
header
yeah
in
the
in
the
api
include.
C
He
has
added
the
dot
cc,
file
and
kind
kind
of
kind
of
trying
to
trying
to
use
this
approach
so
that
we
can
use
it
and
in
a
header,
only
way
also
where
we
can
directly
add
provided
or
cc,
as
include.
C
C
B
C
No,
but
that
decision
would
be
taking
at
length
during
the
linked
time
right,
if
the
the
time
of
linking,
if
it
sees
that
there
is
the
I
mean
at
the
time
of
link
or
link
time
only
it
will.
It
will
try
to
make
that
decision
right
now,
the
link
and
once
once
the
decision
is
made
during
length
time
when,
by
at
the
run
time
we
can.
Can
we
overwrite
that.
C
So,
what's
happening
is
basically
when
the
set
when
the
get
provided
is
called
so
when
the
set
tree
is
provided,
is
called
suppose
at
the
at
the
application
level
it
it
is
going
to
so
each
of
them
will
have
their
own
singleton
object
of
this,
where
it's
called
sorry
the
tracer
provider
this
one
just
because
they
are
not
able
to
see
each
other
like
if
we
are
using
the
flag
hidden.
That
means
that
application
and
all
the
dlns
will
have
their
own
copy
of
this
provider
right
yeah.
C
Since,
since
this
I
mean
it's
in
the
application
at
the
application
level,
normally
the
preference
will
given
for
for
the
for
this
singleton,
which
is
defined
at
the
application
level,
but
since
they're
not
able
to
see
each
other
singleton,
it
assumes
that
they
have
your
own
copy
of
this
singleton
and
they
are
going
to
use
that,
and
so
the
set
provider
tracer
provider
called
at
the
application
level
will
modify
only
the
singleton
which
is
which
is
defined
or
which
is
defined
for
it.
C
For
that
application
and
the
dll,
when
it
calls
get
provider,
it
is
going
to
get
the
singleton
which
is
defined
locally
for
the
dln.
So
that
means
it
will
get
moved
tracer
provider.
It
will
not
get
the
set
traverse
space
provided,
which
is
called
from
the
application,
because,
because
this
I
mean
so
this
correct
me.
This
is
my.
C
B
A
Looking
at
that
branch,
I
see
that
all
the
all
the
inline,
annotations
and
whatnot
are
placed
on
the
methods
themselves,
which
is
kind
of
strange.
I
haven't
well
I've
not
tested
that,
obviously,
but
I
think
it's
broken.
Those
annotations
should
be
on
the
static
provider
itself.
A
A
So
all
the
attribute
with
visibility,
equal
default
or
visibility
with
public
or
things
like
that,
probably
should
be
on
the
the
static
provider
itself.
C
C
C
I
I
I'll
I'll.
I
prefer
the
first
approach,
the
one
which
you
said
where
we
have
the
header
only
and
if
we
can
have
the
annotations
on
this,
that
works
fine,
but
I
mean
somebody
has
to
really
test
it
out.
If
that
works,
fine,
it's
having
the
annotations
on
say
only
the
static
provider,
but
keeping
it
header
only
that
works
it's
fine,
otherwise,
probably
if
we
have
to
modify
if
we
have
to
change,
make
make
our
api
as
more
of
a
shared
library
or
make
it
in
the
source
file.
C
A
C
A
So
so
anyway,
so
this
is
a
new
issue
that
was
reported
recently
and
I.
B
C
C
C
C
B
C
B
C
A
B
C
C
C
A
C
C
C
C
In
the
milestone,
I
think
it's
not
there,
but
let's
keep
it
here,
we'll
see
it
afterwards,
if,
if
it
can
be
done
before
or
after
this,
I
think.
C
C
C
B
B
C
C
C
C
C
Yes,
exactly
yeah,
that's
the
same
with
your
hand
and
it's
recommended
there's
no
exporter
change.
This
is
just
the
change
in
the
recording
one
and
so
on.
Okay,.
C
Yeah
just
adds
a
new
new
virtual
method
in
the
recorded
one
which
can
be
overwritten
by
the
exporters,
and
the
people
want
to
use
it.
They
can.
They
can
write
right,
override
this
method
in
the
exporters
to
deserialize
the
span
and
cream
when
created
in
the
span
data
format.
That's
all
okay,
thanks
everyone.
I
think,
thanks
for
joining,
see.