►
From YouTube: 2022-06-23 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
A
I
just
wanted
to
chat
briefly
about
this
looks
like
natasha's
already
good,
and
it
made
sense
to
me
also
the
idea
of
I
like
the
idea.
I
was
kind
of
thinking
of
something
similar
for
around
like
the
jmx
metrics,
when
we
were
sort
of
battling,
what
jmx
metrics
we
should
capture
and
how
we
should
map
them
to.
The
spec
is
just
a
pure
straight
mapping
of
mb
name
attribute
and
call
that
the
spec,
so
we
don't
have
to
go
through
the
spec
for
naming.
B
Yeah
this
is
this
is
a
tricky
tricky
issue.
There's
a
there's,
a
spec
issue.
That's
open
about
this
topic.
B
I
love
to
comment
that
kind
of
I
summarized
in
the
in
the
in
the
description
of
this
pr,
but
there's
so
you
know,
there's
there's
a
lot
of
systems
that
are
kind
of
in
the
same
category
right
now,
so
the
collector
has
a
lot
of
receivers
that
basically
go
and
scrape
some
sort
of
telemetry,
endpoints
or
apis
that
are
provided
by
various
database
systems,
and
then
we
bridge
those
that
telemetry
into
the
open
telemetry
data
model
and
make
it
available
for
processing
in
the
collector
pipelines.
B
So
that's
one
example,
and
then
we
have
the
jmx
stuff.
That's
another
example.
That's
a
good
one,
and
yet
another
example
is
the
is
micrometer
metrics.
You
know
in
a
similar
way,
so
they
have.
The
micrometer
is
both
like
an
api
and
also
like
like
a
metric
yeah.
They
have
instrumentation
implementations,
and
so
you
know,
arguably,
by
the
same,
if
you
take
the
stance
that
all
open,
telemetry
instrumentation
should
be
codified
in
semantic
inventions,
then
by
bridging
in
micrometer
instrumentation,
we
should
try
to
conform.
B
Those
to
semantic
inventions
or
or
codify
them
in
semantic
inventions-
and
I
think,
like
kind
of
my
realization,
as
I
was
thinking
about
all
these
things-
is
it's
just
completely
impractical
to
do
that
type
of
thing
to
go
through
the
effort
to
get
all
those
you
know
committed
into
the
semantic
inventions,
and
it
doesn't
actually
provide
a
lot
of
value,
and
so
you
know
what
we
want
to
do.
Is
we
want
to
make
these
these
metrics
and
telemetry
that's
collected
from
other
systems
available
as
part
of
the
open,
telemetry
ecosystem,
but
we
have
to.
B
I
guess
we
have
to
be
like
in
tune
with
the
reality
that
these
aren't
systems
that
we
can
control.
So
you
know,
in
contrast
to
the
telemetry,
that
we
write
when
we
inject
telemetry
into
different
libraries
and-
and
we
provide
the
instrumentation
ourselves
all
of
these-
have
in
common
this
kind
of
characteristic
that
we're
just
bridging
them
from
some
other
system,
and
that
system
could
change
over
time.
B
And
so
you
know
if,
if
even
if
we
wanted
to
codify
them
in
semantic
conventions,
we'd
be
making
guarantees
stronger
than
we
could
than
we
could
uphold.
So
because
you
know
that
that
system
could
change
the
metrics,
that
it
exposes
the
attributes,
the
names
and
so
kind
of
kind
of
what
I
was
kind
of
concluding
was
that
you
know
folks
are
going
through
this
effort
of
trying
to
add
these
to
the
semantic
inventions
because
they
want
to
offer
better
stability
guarantees
to
their
users,
and
I
don't
think
it's
necessarily
that
they're
we
wanna.
B
Well,
I
guess,
like
you,
know,
stability
guarantees
can
come
in
a
couple
of
different
forms.
We
can
say
that
we'll
always
produce
this
same
telemetry
or
we
can
have
more
kind
of
behavioral
guarantees
like
we'll
apply
this
same
set
of
rules
every
time,
and
so
as
long
as
the
upstream
telemetry
system
doesn't
change
what
it's
emitting
we'll
apply.
A
And
bruno,
thank
you
for
your
first
review
on
this
issue.
Thank
you,
yeah.
It's
so
helpful
to
have
extra
eyes
on
things
and
feel
free,
like
it's
also
super
useful
to
once
something
you
know
looks
good
to
you
to
actually
approve
approve
it,
even
though
your
name
won't
get
like
a
green
check.
Mark
it'll
still
like
say
that
you
approved
it
and
that's
good
input
for
for,
for
us.
E
B
B
So
kind
of
what
I
just
talked
about
is
you
know.
I
commented
on
this
issue
to
that
same
effect,
and
it
seems
like
there's
kind
of
consensus,
that
it's
impractical
to
make
everything
that
all
telemetry
that's
produced
by
any
open,
telemetry
components
to
to
make
that
to
codify
that
in
semantic
inventions.
B
I
think
people
are
kind
of
on
the
same
page
there
and
so
yeah,
trying
to
figure
out
exactly
where,
where
we
draw
the
line,
I
guess
and-
and
I
guess
like
for
the
components
that
are
doing
this
type
of
bridging
activity
like
how
do
you
offer
stability
guarantees?
That's
kind
of
what
I'm
interested
in
seeking.
A
I
can
definitely
parse
it
in
favor
of
this,
like
in
terms
of
stability.
Guarantee
is,
if
you
upgrade
hotel
components,
we
don't
break,
but
if
you
upgrade
kafka,
then
right
all
bets
are
off
so
nice
yeah.
I
I
think
I
I
must
have
missed
this
issue.
When
I
I
declared
bankruptcy,
spec
repo
bankruptcy,
recently
I'll
I'll
review,
because
yeah
this
is
very
applicable
to
us
and
to
this.
B
B
Metrics
of
this
type
apply
this
transformation
for
attributes
that
look
like
this,
apply
this
transformation
and
and
when
we
do
a
similar
thing
for
micrometer,
but
in
an
unspecified
way
like
it's,
not
it's
not
written
down
anywhere,
it's
just
kind
of
embodied
in
the
code,
and
I
think
that's.
What
like
a
lot
of
these
systems
are
effectively
doing
is,
like
you
have
two
distinct
like
telemetry
data
models,
and
you
need
some
logic:
that
bridges
between
them
so
like
whether
it's
written
down
in
a
specification
somewhere
or
just
embodied
in
code.
C
A
Yeah
john
and
I
wanted
to
bring
up
this
idea,
and
I
think
possibly
david
touched
on
it.
John
and
david
touched
on
it
last
week,
but
we'd
love
to
get
your
thoughts,
jack
and
bruno
from.
Are
you
doing?
Are
you
doing
profiling
currently
in
the
open,
telemetry
world?
A
Meaning,
like
I
know
our
distro,
our
java
agent
distro,
has
a
add-on
sort
of
we've
added
something
to
do
some
job
some
profiling
and
send
profiling.
Jfr
files
to
our
backend
service
and
splunk
has
done
something
similar,
and
I
think
these
are
sort
of
like
interim
solutions
until,
like
the
the
big
open,
telemetry
profiling
story
is
complete,
but
we
were
kind
of.
We
were
looking
at
doing
something
short-term
in
the
java
space.
As
far
as
there's
certain
problems
that
we
could
try
to
upstream.
A
Some
of
this
profiling
stuff,
for
example,
just
triggering
these
recordings
flight
recorder,
is
troublesome
on
different
java
versions
and
different
distros
java
distros
or
the
problem
of
configuring.
If
you
want
certain
events
or
you
want
to
suppress
certain
events
through
the
jfr
configuration
at
runtime
versus
necessarily
having
a
fixed
static
flight
recorder,
configuration.
A
A
B
So
a
little
bit
of
background,
so
new
rolex
has
a
a
jfr
offering
and
you
know
what
what
it
effectively
is
is
it's
it's
a
jar
that
you
can
run
and
it
will
dynamically
attach
to
your
like
a
running
application
and
it
will
start
recording,
jfr,
stuff
and
stream
that
into
this
separate
process,
do
processing
on
it
and
upload
some
statistics
about
that
to
our
platform,
where
you
can
see
all
sorts
of
interesting
profiling
type
details,
we
would
be
we'd
be
happy
if
there
was
an
open
telemetry
equivalent
of
that
type
of
thing.
B
So,
if
you
could
some
open,
you
know
community
driven
effort
to
be
able
to
either
like
add
application
start
or
dynamically
attach
to
a
running
application.
E
B
It's
an
additional
thing:
okay,
so
the
it's!
You
know
it
will
connect
to
your
application.
I
think
typically
over
jmx
and
maybe
I'm
getting
that
wrong,
but
it
will
initialize
the
recording
of
jfr
stream.
Those
jfr
events
out
of
your
application
out
of
process.
E
So
about
gfr
and
everything
related
with
the
flight
recorder
and
my
experience
that
that's
usually
an
accessible
in
production
applications.
E
There's
no
gmx,
there's
no
way
to
to
to
to
to
access
that
information,
because
the
security
guys
they
they
just
shield
all
kind
of
access
to
the
containers.
So
there's
no
way
that
information
gets
out.
So
in
practice
we
can
have
it,
but
we
we
don't.
B
So
I
think
I
think
new
relics
jfr
offering
comes
in
two
flavors
one-
is
this
kind
of
like
dynamic,
attach
thing,
so
it's
a
separate
process
and
it
connects
the
other.
One
is
like
it's
like
a.
I
think
it's
packaged
up
as
in
in
more
recent
versions
of
our
java
agent.
It's
packaged
up
in
the
agent
and
you
can
have
some
feature
flags
that,
like
you,
know,
enable
it.
B
So
if
it's,
if
it's
running
in
that
capacity,
then
it's
just
running
in
process
and
well,
I'm
not
sure
to
what
extent
the
same
kind
of
security
considerations
apply.
To
that
I
mean
if,
if
we
have
this
open
telemetry
java
agent,
that
already
has
like
a
hook
into
the
the
application
and
is
running
in
the
same
process.
You
know
that's
a
that's.
Potentially
a
nice
add-on.
E
Well,
my
experience
that,
usually
you
don't
have
access
to
the
containers
or
to
the
insides
of
the
containers.
E
C
E
That's
that's
interesting,
but
in
the
end,
the
the
results,
for
example,
the
the
the
memory
dump,
it's
considered
to
be
data
sensitive.
So
it's
it's
transferred
through
a
secured
application,
usually,
and
you
have
to
delete
it
after
you
use
it
because
it
contains
that
the
memory
the
objects
in
memory
and
might
contain
pii
yeah.
E
C
C
A
Yeah
yeah
yeah
cinder
lake,
because
that
I'm
not
sure
if.
A
Trust
it,
but
if
it
got
popularity,
maybe
that's
a
great
idea.
E
That's
that's!
That's
interesting!.
A
So
bruno
other
than
I
mean
if
we
set
leaks
sort
of
aside
and
just
the
you
know
just
looking
at
jfr
events
jfr
profiling.
Do
you
see
a
similar
concern
about
that?
As
far
as
I
understand
the
concern
of
attaching
via
jmx,
but
as
far
as
attaching
from
in
in
proc,
via
like
inside
of
the
open
telemetry
java
agent,
for
example,
and
triggering
jfr
recordings.
E
So
threads
absolute
values
of
memory
usage
and
things
like
that
they
are
too
abstract.
So.
A
You're
talking
about
pii
data,
even
within
the
jfr
recording
as
a
bigger.
C
A
Yeah
so
yeah,
so
this
is
a
good.
I
think,
tie
in
to
one
of
the
pieces
that
we
would
like
to
have
in
this
jfr
client
is
the
ability
to
sort
of
dynamically.
When
we
record
of
saying
which
events
we
want
or
don't
want,
and
then
we
could
have
a
list
of
certain
things
like
we
have
this
stock
of
some
flags
that
you
might
want
to
disable
because
of
sensitive.
C
C
C
A
Jack,
I
wanted
to
ask
a
little
bit
more
about
the
do.
You
know
what
so
this
the
neural
like
the
standalone
or
the
in
java
agent
piece
it
triggers
the
recordings
and
then
it
reads
those
in
and
it
does
some
analysis
on
those
before
and
before,
sending
that
to
the
backend
service.
A
B
It's
all
open
source,
so
it
does.
It
does
a
variety
of
things,
some
of
which
has
been
emulated
in
the
the
jfr
prototype
in
in
java
contrib,
because
what's
this
phase
ben
was
kind
of
part
of
one
of
the
leads,
I
think
on
the
jfr
product
at
new
relic.
Oh,
I
see
so
part
of
this
yeah,
but
one
thing.
A
B
One
thing
that's
been
missing
from
this
is
and
kind
of
a
critical
piece
is
the
ability
to
like
record
events
in
open
telemetry,
so
some
of
the
stuff
that
you
would
want
to
capture
from
jfr
events
isn't
a
good
fit
for
metrics
or
spans,
and
so
you
know,
we've
we've
kind
of
been
kneecapped
in
a
way
and
the
ability
to
collect
the
information
that
you
actually
might
want.
Most.
B
So,
like
one
of
the
things
that
I
that
I
like
most
about
new
relics,
jfr
offering
is
like,
like
a
flame
graph
of
where
time
is
spent
in
different
methods
and
in
different
code
paths.
I
think
that's
super
helpful
for
figuring
out
hot
spots
in
in
running
applications,
and
you
know
that
type
of
information
is
collected
and
and
passed
to
our
back
end
via
events
that.
A
B
End
understands
I
I
I
think
it
might
be
somewhere
in
between
honestly,
so
I'd
have
to
go
look
closely.
I
haven't
looked
at
this
code
in
in
over
a
year,
so
I'm
a
bit
buzzy
on
it.
A
So,
where
I'm
at,
like
the
the
open,
telemetry
profiling
working
group,
I'm
imagining
one
of
the
first
priorities,
there
will
be
a
common
otlp
type
format
for
that,
especially
the
execution
profiling,
yeah.
A
B
Some
people
have
proposed
that
you
can
come
up
with
a
semantic
convention
and
put
them
in
in
the
log
data
model,
whereas
as
events
because
logs
and
events
are
the
same
thing.
So
maybe
we
can
repurpose
the
log
data
model
for
that,
but
yeah
we'll
see
where
they
land.
A
B
To
manage
the
recordings,
so
I
think
the
new
relic
jfr
offering
works
in
like
kind
of
two
different
modes,
there's
the
newer.
If
you're
on
newer
versions
of
the
jvm,
I
think
there's
like
a
streaming
api
that
you
can
use
where
you
can
indicate
that
you
want
to
just
listen
to
a
stream
of
jfr
events,
and
then
it
becomes
like
pretty
easy
to
do.
Processing
on
that,
but
older
versions
of
the
of
the
jvm.
B
B
Where
we
end,
we
indicate
that
the
recording
should
be
for
slightly
overlapping
time
windows
and
then,
when
we're
processing
those
we
do
have
some
sort
of
deduplication
process
and
effectively
map
jfr
values
that
were
recorded
to
disk
to
like
a
unified,
deduplicated
stream,
and
then
we
process
it
in
a
similar
way.
So
we
kind
of
reconstitute
a
stream
where
the
stream
api,
where
it
doesn't
exist.
I
think
I
think
that
was
part
of
the
challenge
of
the
the
code
that
we
that
we
produced
is.
B
E
B
Do
we
compress
the
stream
before
we
do
what
so
we're
processing
it
in
in
a
local
process
and
we're
doing
we're
listening
for
select
events
that
we're
interested
in
and
then
doing
some
analytics
on
that
to
transform
those
into
different
like
aggregated
forms
or
other
formats,
and
then
we're
exporting
to
our
our
back
end?
And
so,
when
we
export
in
the
back
end,
we
can
press
that,
but
it's
not
exactly
the
original
stream.
It's
all
like
you
know,
there's
analytics
done
locally
on
it.
E
B
Oh,
you
should
catch
up
with
with
ben
evans.
He'll
he'll
tell
you
all
about
it.
A
Yeah
so
jack
to
answer
kind
of
the
question
of
what
the.
What
we're
sort
of
thinking
of
for
this
jfr
client.
Is
that
there's
a
lot
of
these
kinds
of
things
that
everybody
is
dealing
with
on
their
own
in
each
vendor
is
kind
of
dealing
with,
and
so,
if
we
could
share
that
that
knowledge
and
burden
in
a
central
place,
I
think
we
would
all
we
could
all
benefit.
B
We
yeah,
that's,
that's
possible,
I
don't
think
new
relic
is
like
putting
a
huge
amount
of
investment
in
their
jfr.
Offering
today
you
know
as
popular
as
jfr
is
profiling
seems
when
you
you
take
surveys
in
the
open,
telemetry
community.
I
don't
I
don't
know
how
many
people
are
actually
doing
it
in
practice.
Well,
I
don't
know-
maybe
maybe
I
just
have
foot
and
mouth
here,
but
so
we
don't
have
a
tremendous
amount
of
customers
that
are
like
clamoring
for
it
and
better
features
and
so
like.
B
If
there
was
an
improvement
in
the
client
capabilities
of
this,
I
don't.
I
don't
know
that
there
would
be
an
engineering
team
to
prioritize
going
out
and
using
that
now,
if
there
was
a
like
an
alternative
source
of
jfr
data
like
that
was
generated
by
some
open
telemetry
library,
and
it
contained
this.
The
information
needed
to
to
do
this.
You
know
the
the
flame
graphs
and
the
continuous
profiling
type
stuff.
I'm
sure
that
we
would
build
in
capabilities
in
our
platform
to
analyze
that
data
and
do
useful
things
with
that.
B
A
Yeah
and
so
potentially
for
a
vendor
like
new
relic.
That
already
has
a
you
know
a
mature
kind
of
profiling
offering-
and
you
know
you
have
the
mature
java
agent
as
potentially
that
a
door
here
would
be
for
as
we
integrate
this
into
the
open,
telemetry
java
agent,
and
then
your
customers
could
benefit
that
way.
A
Yeah
yeah
yeah,
but
I
was
kind
of
curious
to
see
what,
if
there
were
advantages,
if
there
was
interest
in
this
kind
of
thing,
pre
having
that
full
path,
but
just
starting
to
solve
some
of
these
problems
from
a
recording
perspective.
B
Yeah,
so
I
you
know,
I
I
I've
worked
loosely
with
that
team,
but
I'm
not
on
that
team,
so
I'm
not
sure
exactly
what
their
challenges
are
and
whether
what
their
appetite
is
for
alternative
solutions.
So
I
can't
say
for
sure,
but.
A
Yeah
well
this.
This
gives
us
also
something
else
to
kind
of
look
at
to
see
what
kind
of
imp
just
from
the
source
code
the
we
can
kind
of
get
a
sense
of
the
implement.
Other
potential
challenges
like
this
one,
I
think,
is
really
interesting
and
we
hadn't
thought
about
from
a
continuous
profiling
perspective,
because
in
in
our
product,
it's
a
little
more
targeted
at.
A
On
certain
triggers
triggering
profiling
on,
like
performance,
regressions
kind
of
a
thing
versus,
but
I
know
that
continuous
profiling
is
super
popular
also,
so
that
that
would
be
a
challenge
that
we'll
have
in
the
open
telemetry
space
for
sure.
B
Yeah
that
the
continuous
profiling
piece
is
super
attractive
to
me,
like
you,
have
a
like.
You
notice
that
application
in
production
is
behaving
funny.
You
exact
into
that
container,
attach
a
process
to
it.
So
you
can
start
like
you
know
like
monitoring
it,
and-
and
you
extract
that
data,
you
just
push
that
data
directly
to
some
platform
like
new
relic
or
some
other
platform,
and
you
can
get
insight
into
this
one
specific,
badly
behaving
application.
B
I
mean
I
know
you
can
do
that
type
of
thing
with
jfr
today,
but
it's
like
pretty
annoying
to
like
to
indicate
that
you
want
to
start
doing
jfr
recordings
and
to
export
those
those
recordings
out
of
your
your
box
and
then
do
the
the
analytics
locally
and
whatever,
whatever
tool
you
use
to
import.
Those
like
that.
That
workflow
is
just
not
very
good.
A
Well,
you
have
in
new
relic
through
the
portal
you
can
trigger
on
demand
a
profile.
I
think
right.
B
Yes,
it's
a
it
doesn't
work
through,
I'm
not
exactly
sure
how
it
works,
but
it's
not
jfr.
A
Stopping
us
yeah
yeah
when
I
had
used
it
many
years
ago.
I
thought
I
would
call
it
giving
if
you
triggered
that
it
would
give
you
execution
profile
like
the
big
execution
tree
for
that
time,
which
may
not
be
from
jfr
but
may
just
be
from
doing
thread,
get
all
stack.
Traces.
A
Oh
sorry,
I'm
just
keep
picking
your
brain
jack
another.
That
might
be
another
thing.
Do
you
happen
to
know
the
if
the
new
relic
java
agent
still
does
a
javascript
injection
for
the
rum.
B
I
think
I
I
think
we
did
something
like
that
and
we
might
still
do
it,
but
I
think
it's
always
been
finicky
for,
for
I
don't
know
for
reasons
that
you
can
probably
imagine.
A
Yeah,
okay,
cool
yeah
yeah.
Well,
we
have
a
intern
project
to
doing
javascript
injection
in
the
open,
telemetry
java
agent
and
so
they've
gotten
to
the
point
of
you
know-
and
I
am
very
well
aware
of
the
like
it's
a
notoriously
finicky
problem
but
they've
gotten
to
the
point
where
you
know
the
basics
are
working,
and
so
I
was
gonna
have
them
go
and
look
at
next
analyze,
some
prior
art,
yeah.
A
Yeah,
I
I
I
gave
them
the
the
the
repo
and
I
was
like.
A
E
So
my
next
big
aim
well
at
the
mid
mid
term,
would
be
to
see
if
we
can
integrate
micrometer
metrics
into
open
telemetry,
but
writing
data
directly
to
the
sdk
to
use
the
the
aggregations
there
and
well
jump
the
the
need
for
the
registry.
A
So,
to
allow
cusp
users
to
still
use
the
micrometer
apis,
yes,
and
so
have
you
seen
and
is
it
something
different
from
this?
Have
you
seen
this
project.
D
Here,
no
maybe
it's
that
thing.
E
A
Check
this
out
what
it
that
what
it
does
sounds
the
sounds
like
what
you
were
describing
at
least
where
you
still
use
it's
a
micro.
It
provides
a
micrometer
registry,
but
under
the
hood,
everything
goes
to
the
open,
telemetry,
metrics
sdk,
and
so
it
uses
all
the
aggregate.
All
the
aggregations
happen
in
the
open,
telemetry
metrics
sdk,
which
means
also
you
get
well.
Do
you
get.
B
Yeah
as
long
as
it's
happening
in
the
current
thread
and
it's
yeah-
it's
not
like
you
know,
micrometer
doesn't
go
and
execute
this
on
a
different
thread
which
would
be
unexpected
and
as
long
as
you're,
using
an
instrument
that
supports
exemplars.
B
Which
yeah,
which
instruments
do
or
don't
do
you
know
yeah?
So
the
the
big
thing
is
just
that
asynchronous
instruments
do
not
have
exemplars,
oh,
which
makes
sense
yeah
and
histograms
counters
and
up
down
counters
all
do
so.
E
E
E
A
Yeah,
I
would
love
your
review
and
thoughts
on
the
the
vertex
instrumentation
that
we
have,
if
there's
potentially
better
ways
to
be
instrumenting
this,
or
also
we
don't
have
any
all
of
our
vertex
instrumentation
is
java
agent.
Only.
A
E
So
vertex
has
some
hooks
that
libs
can
can
hook
into
to
to
get
metrics
and
things
like
that.
And
but
but
it's
it's
hard
to
to
understand
which
which
call
belongs,
which
request
at
each
given
time.
Because
of
the.
A
A
Yeah,
so
we
do
that's
kind
of
what
divert
this
instrumentation.
A
At
least
the
web
and
rx
java
instrumentation
do
for
the
java
agent
is
to
track
that
thread
hopping
for
vertex
requests
and
to
set
the
current
context
so
that,
if
you
use
like
make
a
jdbc
call
inside
of
your
vertex
handler,
it'll
get
correlated
back
to
the
request,
but
sometimes
there's
sometimes
we
don't
always
know
the
best
hooks
and
we
do
something
that
works,
but
maybe
there's
better
or
maybe
there's
better
things
in
newer
versions
that
we
could
hook
into
and
then
in
the
future.
A
As
you
have
something
that
works
out
of
the
box
like
without
the
java
agent.
As
far
as
that
support,
we
would
love
to
hook
into
maybe
that
in
the
java
agent,
as
opposed
to
having
our
own
thing.
E
Right
yeah,
I'm
still
doing
things
myself,
yeah.
E
I
will,
I
will
remember
this
yeah
so,
but
before
I
I
fly
into
these,
I
would
like
to
ask
you
guys
so
there's
a
bunch
of
issues
on
the
on
the
the
instrumentation
project
in
the
sdk.
E
A
I
can
definitely
I'm
always
happy
to
it
usually
takes
me
a
little
bit
of
going
through
and
looking,
but
I'm
always
happy
to
do
that
anytime.
Somebody
is
looking
for
wants
an
issue
to
work
on,
so
why
don't
I?
I
will
put
that
on
my
action
item
list.
A
It's
sometimes
challenging,
based
on
but
yeah
that
we
should
do
a
better
job
on
that,
I'm
not
sure
a
lot
of
the
issues,
it's
hard
to
say
like
I,
I
worry
like
a
good
first
issue
and
then
you
like
crack
it
open
and
there's
like
a
whole
can
of
worms
there,
especially.
B
B
E
Well,
I
I
not
meant
like
easy
issues.
Well,
they
should
be
not.
They
should
be
not
that
hard,
but
so
issues
that
kind
of
are
around
important
things
that
you
need
to
understand
and
by
solving
them
you
actually
learn.
A
D
A
Good,
potentially,
a
good
label
to
search
by
is
repro
provided.
E
A
B
A
If
you
sort
of
post
back
to
the
issue
that
with
sort
of
your
findings
so
far,
then
that
could
help
other
people.
We
can
either
brainstorm
on
that
issue
or,
if
somebody
picks
it
up
later,
they
can
have
some
additional
context.