►
From YouTube: 2022-10-10 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
B
Hi
good
evening.
A
B
B
From
our
side,
I
think
we
just
need
to
regenerate
the
schematic
conventions
and
that
should
hopefully
that
should
be
the
only
thing
which
is
which
we
need
to
work
on
this.
Then
there
is
a
issue
on
Matrix
semantic
convention
not
specified
in
the
yaml
file.
This
is
a
bit
old
issue,
but
I
think
just
wanted
to
bring
it
here,
because
probably
we
may
have
to
do
some
changes
whenever
this
gets
supported.
So
as
of
now
they
have
done.
B
There
is
some
work
done
on
some
private
Branch,
but
I
don't
think
it's
as
of
now
anything
close
to
any.
Oh,
it's
and
I
believe
it's
close
to
it
being
very
for
much.
Okay,
so
probably
I
think,
let's
hope
that
in
near
near
time,
I
think
probably
some
work
is
done
here
on
them.
We
should
be
able
to
get
our
symmetric
conventions
generated
foreign.
B
Ification
needed
for
exporter
reader
contribution,
I
think
these
boundaries
between
exporter
leaders
still
that
expressions
are
happening.
The
boundaries
are
not
very
clear.
Where
should
we
configure
or
the
temporarily
so
as
I
said,
exporter
is
somebody
who
knows
how
the
Upstream
systems
they?
What
kind
of
data
format
they
handle
it?
So
they
are
the
best
place
to
configure,
but
I
think
it's
still
getting
discussed
of
both
C
and
D.
So
we
may
need
some
changes.
B
Just
waiting
for
more
clarity
on
this
click
clarify
the
attribute
support
based
on
stable
wire
protocol
definitions
of
attribute.
This
is
also
again
being
discussed
last
week
on
TV.
We
talked
about
this,
so
we
may
have
to
change
or
we
have
to
decide
if
we
have
to
do
any
changes.
If
understood,
attributes
are
getting
supported
as
if
not
they
are
not
supported.
But
if
something
happens,
we
have
to
add
a
support
on
this
or
we
have
to
decide
whether
we
have
to
support,
because
that
will
change
that
will
need
a
change
in
our
API.
B
The
variant
object
which
we
have
so
probably
will
you
can
discuss
it
afterwards,
logs
SDK,
we
had
a
discussion
in
the
discussion
forum
in
our
repo
and
who
want
is
on
vacation
and
I'll,
create
the
task.
I
think
we
agreed
had
a
discussion
with
owent
in
that
I
think
we
agreed
how
to
proceed.
So
based
on
that
I'll
create
the
tasks
for
that
probably
have
a
separate
Milestone
or
the
project
for
log
SDK,
and
all
the
tasks
will
go
under
that,
so
that
we
should
be
able
to
track
them
properly.
B
So
I
I'll
do
that,
probably
today
or
maybe
by
tomorrow
will
be
done.
So
then
there
is
a
discussion
starting
for
supporting
the
dynamic
logging
I'm,
not
sure
how
much
relevant
it
is
for
C,
plus
plus,
but
there
are,
there
are
some
products
which
supports
Dynamic
logging
of
logs.
So
that
means
what
it
means
is
that
at
the
runtime
at
the
production
environment,
you
should
be
able
to
inject
the
locks
based
on
your
need,
not
just
enable
the
logs
but
inject
the
logs
in
the
code.
B
Where
are
we
want
to
actually
dump
the
required
log?
So
that's
something
I'm,
not
sure
if
that's
delete
relevant
or
whether
we
can
do
anything
for
C
plus
plus.
This
may
be
relevant
for
the
libraries
where
which
basically
has
the
source
code
deployed
as
a
pressure
environment
or
the
byte
code
is
deployed
at
the
production
environment.
I'm,
not
sure
whether,
however,
anybody
could
be
in
a
c
plus
place,
but
probably
good
good,
to
have
an
eye
on
that.
B
It's
something
we
have
to
do
here
in
case
in
case
the
support.
Is
it
yeah
and
structured,
stack,
traces
and
span
attributes?
That
was
another
discussion
which
is
started
and
so
still
I.
Think
not.
Everybody
is
agreeing
whether
we
should
support
restructured
attributes
for
the
structures,
structures.
Format
is
different
across
different
languages,
so
whether
you
can
have
a
common
format
to
support
it
as
part
of
attributes.
Those
panel
locks
so
I
think
the
discussions
are
happening.
B
We
do
support
adding
the
exceptions
as
part
of
Trace
API,
which
we
don't
support
in
open,
Telemetry,
C
plus
plus.
So
there
is,
there
is
a
record
exception
in
precipia
I.
Think
in
the
spanned
report
exception
where
you
can
record
an
exception,
but
we
we
don't
support
it
in
open,
terribly
C,
plus
plus,
because
I'm
not
sure
why
we
didn't
error
support,
maybe
because
we,
our
code
at
least
our
API
in
SDK,
does
not
log
any
exception.
B
So
probably
we
just
decided
that
it's
not
support
this
API
and
anyone
who
wants
to
log
any
exception
they
can
use
the
untpi.
They
can
use
the
undpa
to
log
it.
So
it
is
not
not
supported
that.
That
thing
is
not
supported
in
open
derivators
you
just
please
but
yeah.
This
is
something
which
is
being
discussed.
B
You
know
that
that's
what
I
could
figure
out
the
recent
discussion
which
were
happening
so
just
just
added
them.
Just
let
me
know
there's
something
else
which
I'm
missing
you
can
discuss
it.
You
know
or
open
Telemetry
demo
I
think
there
is
one
ask
I
just
created
an
issue
for
that.
There
is
an
Ask
coming
ad
hoc
from
the
slack
for
adding
this
service
documentation
for
Currency
Service.
B
So,
basically,
in
the
demo
we
have
different
services,
for
instance
those
each
other
languages.
So
the
Currency
Service
is
something
which
is
written
in
which
is
written
for
C
plus
space
and
that
just
Maps
the
currency
for
various
countries.
That
is
basically
that
just
creates
an
Hash
Hash.
You
know
data
structure
to
store
the
currencies
and
just
return
the
right
currencies
for
that.
It's
very,
very
basic,
minimal
code,
but
they
need
some
documentation
here.
B
B
That's
a
good
add-on.
I,
don't
think
promise
books
exporter
is
is
used
very
predominantly,
but
I
think
it's
a
good
add-on,
which
somebody
did
you
want
to
use
it.
It's
mostly
the
problem
with
this
pole.
Exporter
is
something
which
is
used
and
we
already
have
it
in
our
main,
repo
and
yeah.
Apart
from
that,
I
think
there
is
some
work.
I
was
doing
for
instrumentation
instrumenting
in
the
process.
This
Matrix
is
still
work
in
progress.
B
Hopefully,
in
coupled
couple
of
days
it
should
be
ready
or
review
will
request
of
the
you
guys
can
review
it.
I
mean
I,
don't
know
who
else
can
review
out
of
the
parts
of
our
team
in
this,
so
that
just
act?
It
provides
the
abstraction
for
Linux,
as
of
now
to
calculate
the
various
Matrix
using
the
proc
file
system.
Technical,
you
basically
just
accesses
the
profile
system
and
purchase
all
the
Matrix
and
send
it
across
across
collect
all
the
measurements
and
send
it
across
as
Matrix
to
the
destination.
B
Oh
yeah,
it
still
still.
Some
work
is
required
and
I
think
probably
start
with.
It
could
be
only
for
Linux
and
then
probably
we
can
add
some
something
for
Windows,
also
and
there'll,
be
required
for
Mac,
also
yep
and
taking
most
of
the
stuff.
I
think
this
is
already
supported
by
Python
and
dotnet.
So
I've
just
taken
some
of
the
tips,
how
they
are
doing
it
and
just
just
integrate
it.
B
A
B
B
Yeah,
that's
that's,
I
mean
I,
don't
have
any
strong
opinion
not
doing
it.
The
only
thing
is
that
we
don't
do
any
validation
if
those
tests
are
really
passing.
It's
just
that
we
can
get
some
of
the.
We
can
catch
some
of
the
errors
using
a
silent
design.
We
are
not,
we
I
mean
we
won't
be
validating
anything
out.
A
A
B
A
B
A
B
A
B
Yeah,
okay,
probably
I
will
look
if
there
is,
if
you
feel
there
is
any
issue
just
between
two
days
of
work.
For
that
nothing,
it
would
be
same
I
hope
so
I
mean
there's
insurance.
B
B
B
I
yeah:
let's:
let's
do
that?
Probably
it's
possible
if
it's
coming
from
Matrix
per
meter,
it
could
be
related
to
that.
B
Yeah
possible
possibility
once
that
is
merged.
I
think
we
can
once
again
and
see,
but
yeah
I
think
I
realized
that
I
didn't
write
enough
test
spaces
for
multiplication
scenario.
Probably
I
should
have
done
it.
Otherwise,
while
writing
the
tests.
B
These
issues
yeah
this
one
again.
This
has
a
race
condition
between
while
we
are
creating
the
instrument
and
where
we
are
collecting
it.
So
it's
possible
that
while
we
start
thematic
collections
still,
there
were
some
instruments
getting
registered
and
the
internal
adapter
section
which
we
use
in
meters.
These
should
be
atomically,
atomically
updated,
so
they
were.
B
They
were
not
that
safe,
so
I,
just
use
the
logs
to
meet
the
defensive
I
feel
that
once
this,
because
this
this
is
the
outermost
I
mean
this
is
the
start
of
the
Matrix
pipeline
for
both
measurement
and
color
and
collection.
B
So
we
I
have
also
created
some
Matrix
locks
in
internal
data
section,
probably
we
can
remove
them,
because
now
that
we
are
already
guarding
the
intern,
the
external
apis,
the
the
I
mean
the
external,
the
apis,
which
basically
I
mean
that's
how
the
pipeline
entity
starts
both
for
collection
and
for
management.
So
if
we
are
ensuring
that
we
are
not,
we
are
thread
safe
at
this
level,
probably
internally
also,
we
won't
be.
B
B
Yeah,
this
is
just
basically
I
just
created
for
discussion.
I
have
been
using
for
some
time
internally
to
create
these
packages,
both
for
open,
Telemetry
and
or
external
contrib
exporter.
Our
external
exporters,
so
I've
been
using
this
kind
of
setup
for
generating
these
packages
and
they
have
been
used
by
some
of
our
teams
internally.
So
I
just
felt
that
probably,
if
somebody
really
want
to
use
it,
I
mean
again,
we
are
not
providing
any
binaries
we
are
not
going
to.
B
We
are
not
going
to
kind
of
ensure
that
whatever
goes
into
the
into
into
these
packages
it's
thoroughly
based
on
how
the
cmake
builds,
the
CMA
configurations
are
being
used.
I
mean
the
all
the
packages.
All
the
dependencies
would
totally
depend
on
that
so
but
yeah
I
think
I
saw
some
very
good
comments.
Coming
from
Mark
try
to
reply
them.
B
A
B
But
yeah
I
don't
have
very
strong
opinion.
I
mean
if
you
all
feel
that
this
is
not
something
which
is
which
is
good
to
have
it
it
will.
It
will
increase
our
I
mean
we
have
to
spend
more
time
on
really
kind
of
managing
it
with
the
driver
management
management
is
going
to
increase
because
of
this
I
think
you
can
should
be
okay.
Do
not
not
do
it.
A
B
B
A
B
B
B
A
Yeah,
so
this
is
the
number
of
yeah
this
morning
and
I'm
closing
in
on
the
very
last
errors
to
fix
that.
So
there
is
an
end
to
to
these
things.
B
A
A
Is
compiled,
some
code
is
generated
by
first,
first
I,
don't
remember
free,
and
that
could
also
contain
some
warnings.
We
have
to
do
the
same
thing,
but
is
done
for
grpc,
which
is
to
have
a
prefix.
B
A
B
A
A
Very
very
minor
thing,
which
is
related
to
the
elastic
surgery
exporter.
There
is
a
switch
case
somewhere
on
on
the
Nina,
and
a
lot
of
cases
are
missing.
Probably
you
know
so
it's
because.
A
A
Well,
it's
missing
cases.
B
A
B
B
A
B
Okay,
yeah
yeah,
thanks
just
to
add
I,
think
there
have
been
discussion
happening
to
drop
this
dagger
tript
exporter,
the
reason
being
that
Jagger
supports
the
otlp.
So
probably
the
OTL,
a
otlp
exporter
can
be
used
by
using
the
correct
endpoints
once
either
they
can
use
it
for
zagger
export
for
Jagger.
So
probably
different
discussion
happening
it's
good
to
drop
it
yeah.
A
B
B
B
I
think
that's
all.
We
have
removes
yeah
I'm
kind
of
low
priority
on
this
and
I
think
this
is
also
it's
more
for
Windows.
So
it's
trying
to
keep
it
open
as
up.
B
B
We
have
to
do
it,
it's
just
that
we
don't
have
enough
resources
to
do
it.
Okay,
that's
the
only
constraint
here
and
but
eventually,
and
the
problem
is
not
just
moving
it
there.
The
problem
is
how
we
have
to
ensure
that
then
we
move
it
such
a
way
that
they
are
building
and
running
properly,
so
yeah,
so
it
means
we
have.
B
B
Yeah,
probably
would
be
now
the
open,
Telemetry
CPP
would
be
one
of
the
dependencies
is
they
have
so
how?
How
will
that
be
taken
care
and
all
those?
So
some
of
the
things
probably
we
have
to
change,
not
just
the
internship,
the
code,
but
also
the
build
their
build
recognitions
and
how
they
are
doing
it.
B
So
that's
that's
something
I
think,
probably
it's
you
know
would
be
substantial
work
and
it
should
I
should
not
have
been
there
at
the
first
go
and
I
was
always
opposing
both
of
these
not
to
be
their
elasticsearch
and
etw
right
from
the
beginning,
but
didn't
have
much
say
at
that
time.
B
B
That
relies
on
the
etw
exporter
and
we
do
create
packages
for
that
yeah
so
that
that
needs
to
be
handled.
We
are
going
to
do
that.
It
will
break,
but
you
have
to
again
take
care
of
that
yeah.
B
B
Yes,
so
yeah
that
that's
what
I
think
it
definitely
needs
some
probably
at
least
existing
bill
should
build
scripts
has
to
be
modified.
Then
we
have
to
internally
take
take
care
of
our
neighbor
packages,
which
we
can
get
for
for
Geneva
exporter,
so
yeah.
A
So,
whenever
I'd
move
up
and
it
most
likely
means
that
we
will
need
to
do
a
synchronized
release
of
both
open
Geometry,
CPP
and
contrib
CPP.
B
Yes,
we
should
be
doing
right
now,
but
I
mean
it's
totally
fine.
If
we
first
move
it
there
kind
of
copy
it
there
and
then
remove
it
once
we
are
sure
that
there
are
no
issues
coming
with
this,
then
we
should
clean
up
so
for
some
time.
Let
it
be
at
both
the
places.
I
mean
I,
don't
think
that
should
be
a
problem.
It
will
tell
you
a
very
sure
that
it's
not
going
to
affect
any
of
the
existing
customers
who
are
using
it,
giving
them
giving
them
some
time
to
change
their
Scripts.
B
B
B
So
it's
totally
fine,
even
if
we
do
it
post
real.
So
if
not,
but
it's
not
prioritizing
it.
As
of
now
issues,
let's
quickly
see
yeah
thanks.
We
already
discussed
this.
The
this
animation
end-to-end
test,
histogram
graphics,
with
more
than
the
default
number
of
boundaries,
yeah
I,
think
tank
is
output
for
taking
it
up,
supporting
changing
aggregation
types
using
views.
That
was
something
which
we
deliberately
not
supported
as
of
now
as
of
now,
if
we
see
the
code
based
on
the
type
of
instrument
we
create
and
default
aggregation.
B
B
B
So
this
this
is
a
default
aggregation
which
we
select
based
on
the
kind
of
instrument,
but
that's
not
the
proper
and
that's
a
proper
way,
but
there
may
be
the
user
who
want
to
use,
say
bucket
industry
histogram
aggregation,
even
if
it's
a
counter
and
which,
which
is
which
is
a
fair
call
to
want
to
do
it
or
maybe
maybe
not
or
maybe,
for
a
synchronous
counter
any
of
them
or
maybe
for
the
gauge.
They
want
to
do.
I
think
that's
a
right
example.
B
If
per
gauge,
they
want
to
use
the
explicit
bucker
aggregation,
not
the
last
value
aggregation
they
want,
then
this
they
want
in
the
bucket
at
least
how
these,
how
the
these
are
coming.
So
the
user
may
want
to
use
different
aggregation,
and
as
of
now,
we
don't
support
it.
We
do
have
to
eventually
support
it.
That
will
need
some
changes
in
our
existing
code
and
as
of
now,
keeping
it
keeping
it
post
ga
unless
and
until
there
is
some
ask
coming
from
customers
to
for
the
users
to
really
support
this
mapping.
B
B
A
B
So
we
do
have
some
default
resource
detectors.
That's
the
template.
I
think
we
just
have
only
one
of
the
detectors,
probably
otlp.
Let
me
just
see
SDK
research
is
rules.
You
know
we
probably
only
have
otlb
yeah.
We
only
have
otlp
resource
directory,
so
they
may
want
to
get
container
resource
detector
and
try
to
get
environment
variables
from
there.
B
B
A
B
A
A
lot
of
issues
on
open,
Telemetry,
IO
itself
for
all
the
documentation.
B
Okay,
well,
they
have
done
it
should
be.
B
B
B
I,
have
this
has
been
I
mean
you
agreed
with
them
right
to
assign
it
to
you?
Yes,
yes,
okay,.
B
B
B
A
B
It's
with
you
and
it's
okay
to
just
have
it.
You
have
for
you
in
64,
as
of
now
sorry
in
164,
in
64,
not
even
in
64,
and
probably
afterwards,
you
can
see
support
more
types.
B
Up
to
this
one,
the
receiver,
basal
okay,
it
will
be
it's
yeah.
This
is
I
think
we
already
discussed
this.
We
have
to
add
it
probably
I
think
once
Matrix
is
logically
viewable,
you
can
start
picking
some
of
these
stuff
documentation
and
open
Telemetry
I
will
discussed
that
we
handle
partial
success.
This
also,
we
have
to
take
events
matrixes.
B
B
So
I
created
two
Milestones
one
is
for
Port
ga,
and
this
one
is
G4
1.2,
post
GA
just
have
as
of
now
two
of
them
exponential,
histogram
aggregation
and
aggregation
type
support,
changing
dedication,
types
using
views,
this
one
okay,
this
is
okay,
Builder,
your
I
think
probably
marked.
If
you
feel
I
think
this
we
can
move
it
as
part
of
post
GA.
Also,
I,
don't
really
want
to
have
to
I
mean
it's
something.
We
definitely
have
to
do
it,
but
this
won't
need
to
this.
A
B
As
of
now
I
think
there
would
be
most
conflicts
for
sure
I
mean
afterwards.
We
have,
there
would
be
lots
of
changes
happening
in
I
mean
I,
do
see
some
changes
happening
in
the
in
the
API
and
the
SDK,
so
I
mean.
If
we
do
it
now,
I
mean
probably
we
have
to
again
redo
all
those
things.
Some
of
those
things
change
it.
You
know
again,
okay,
so
so
one
of
the
things
still
I
want
to
discuss
it.
I
will
create
the
issue.
I
mean
the
things
like
we.
As
of
now.
B
We
release
the
shared
pointer
for
the
instruments,
whether
we
should
be
really
returning
a
shared
pointer,
or
it
should
be
just
a
unique
pointer
so
that
some
some
of
the
changes
in
the
apis,
whether
we
have
to
still
finalize
foreign.
B
B
In
memory
exporter
also
I
think
it's
good
to
move
it
post,
ga
I
mean
I,
really,
don't
see
it
but
required
we
already
have
hosting
exporter,
so
we
don't
need
it
definitely
good
to
have
it,
but
something
which
we
can
deliver
it
afterwards.
Also.
B
Just
just
say
it's
good
to
see
whether
what
how
the
other
six
are
doing
it
and
what
the
specs
talk
about
before
really
implementing,
so
just
have
a
look
into
that.
Also,
you
know
remove
circular
dependencies
here,
I'll
start
working
on
that
I
mean
it's
something
which
is
therefore
some
time
now
clean
up
of
all
this
would
be
a
bigger
task.
I
think
it
should
have
to
be
taken,
I
mean
as
early
as
possible.
I
think,
probably
if
it
is
29th,
we
should
be
taking
it.
A
B
Already
behind
the
feature
flag,
so
there's
no
point
to
make
it
Obsolete
and
then
already
we
have
documented
that
we
are
going
to
remove
it
as
we
are
nearing
to
the
stable
release
of
the
new
Matrix.
This
is
already
documented.
So,
let's,
let's
do
a
cleanup
once
for
and
all
I
think
we
will
definitely
lots
of
unnecessary
code
will
be
removed
from
our
Depo.
A
B
A
B
Yeah,
the
let's,
let's
just.
B
B
A
B
B
A
B
B
Yeah,
probably
I
think
my
understanding
at
that
time
was
that
we'll
remove
it
as
part
of
reaching
the
ga
once
we
have
to
the
ga,
but
I
think
we
all
agree
that
let's
do
it
after
GA,
that's
totally
fine
I,
don't
see
any
reason
why
we
should
be
doing
it
before
we
can
remove
it
from
the
build,
but
I
think
you
can
keep
it
if
we
want,
we
can
just
remove
everything
at
once,
instead
of
doing
it
in
two
phases,
if
you
want
to
let's,
let's
do
a
clean
up
once
for
and
all
I
think
we
can
move
it
from
the
scripts.
B
We
move
it
from
the
from
the
code.
I
mean
delete,
delete
all
the
whole
Matrix
code
base
and
remove
those
macros
and
I
mean:
let's
do
it
post
ga.
So
if
that
was
understanding,
I
think
that's
totally
fine
to
do
it
afternoon.
A
How
I
see
it
we?
We
can
remove
it
after
ga,
but
will
be
less
risky.
We
could
decide
to
remove
it
right
now
and
just
get
rid
of
a
code
and
and
only
support
the
new
metrics.
What
what
is
risky
and
can
cause
a
lot
of
trouble
with
the
make
file
is
to
remove
that
at
the
last
minute,
because
a
lot
of
cmake
file
will
be
touched.
Some
error
file
will
be
reformatted
because
there
is
a
upon
Define
which
is
removed.
Things
like
that.
So
I
think
we
should
not
do
that.
A
Basically,
either
very
early
or
very
late,
but
not
not
before
I,
don't
know
what
you
think,
but
I
I
think
it
doesn't
have
risk
for
us.
It.
A
Just
a
surprise
for
the
users
like
they
just
get
the
new
version
and
everything
is
gone.
That's
the
main
issue,
but
yeah.
B
B
B
A
I
mean
if
we
don't
want
to
remove
code,
maybe
like
you,
can
keep
it
there,
but
we
Emit
and
like
even
an
error
in
our
code.
If
the
user
tries
to
Define
their
metrics
preview,
but
if
the
user
would
like
he
can
remove
the
error.
Somehow
so
it'll
like
give
give
them
a
explicit
break.
But
if
they
want
to
use
that
at
the
camera
they
will
be
aware
it
will
be
removed
later.
B
A
A
B
B
I
think
it's
such
I
think
it's.
It's
stormy
thing
that
to
me
it
makes
sense
that
we'll
error
on
the
cmake
list.
We
won't
let
them
continue
it.
They
can.
They
have
a
workaround
to
do
it
so
that
they
don't.
They
know
that
it's
something
which
is
going
out
very
soon
and
after
the
ga
we
are
doing
a
proper,
full
cleanup,
hello.
A
Out
of
curiosity
is
the
old
metric
implementation
already
working
I
mean,
as
someone
tried
to
do
an
end-to-end
test,
all
the
way
to
permate
use,
for
example,
I'm
asking
because
when
I,
when
I
tried
with
the
current
implementation,
I
think
in
late
May,
we
were
seeing
still
a
lot
of
orders
there.
So
but
I
don't
know
what
is
exactly
the
status
of
the
old
metric
implementation.
B
B
B
B
Okay,
so
I
think,
let's,
let's
follow
this
error
out
in
Gmail
after
the
it
should
not
need
a
major
changes
in
the
existing
existing
pneumatrix
code
files.
We
do
have
to
remove
those
macros
in
the
code
file,
but
I
think
we
need
to
do
Cleanup
in
the
scene
date
and
the
reason
yeah,
but
I
think
that
should
be
planned.
B
Probably
so
if
that
is
something
which
we
agree,
I'll
be
happy
to
move
it
to
host
ga
and
then
we'll
create
a
separate
issue
for
like
a
separate
PR
board,
erroring
out
the
scenic,
and
hopefully
the
laser
Bend.
Also
if
it
is.
B
B
A
Just
to
say
that
for
PR
in
general
I'm,
so
I'm
I've
been
working
mostly
with
Tracy
so
far
in
in
the
code
I'm
I'm,
using
also
for
Telemetry,
so
for
traces,
I'm,
okay
for
metrics
I'm,
not
totally
familiar
yet
with
the
specs
and
how
metrics
works.
So
I'll
do
my
best
to
do
code
reviews
but
I,
don't
know
this
area
well
enough.
Yet.