►
From YouTube: 2023-03-29 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
C
B
Yeah
good
I
think
we
can
start.
A
Hey
yeah,
so
this
is
kind
of
a
bunch
of
different
topics:
I'm
working
on
nullables
working
on
enabling
Nobles
across
projects.
One
of
the
things
I
need
is
the
nullable
attributes
from
the.net
repo
they
ship
with
net
standard
2.1
and
let
the
net
core
libraries
and
because
we
target
older,
like
the
net
standard
2o
net
462.
We
just
have
to
copy
these
attributes
into
our
project.
A
That
by
itself
is
not
a
big
deal,
but
then
the
question
becomes
where's
the
right
place
to
store
them,
and
this
in
particular,
I,
think
people
were
just
kind
of
doing
it
as
needed.
So
I
found
some
of
them
were
stored
in
the
open
Telemetry
project.
Some
of
them
were
stored
in
the
open,
Telemetry
dot,
API
project,
and
it
wasn't
really
clear
to
me
if
there
was
been
decided
like
hey.
This
is
the
best
place
to
put
you
know
like
internal
things.
A
I
can
see
a
lot
of
other
projects
in
our
repo
do
like
the
compile
include
from
both
open
Telemetry
and
the
open,
Telemetry
API,
sometimes
both
in
the
same
project.
So
I
don't
know
that
we
have
a
like
an
explicit
like
hey.
This
is
where
we
want
to
put
internals,
so
that
was
one
question
that
I
had
for
this.
A
In
particular,
it's
got
to
be
in
the
dot
API,
that
is
the
lowest
project
on
the
like
the
dependency
hierarchy
and
the
oldtel.api
project
makes
its
internals
visible
to
the
open
Telemetry
project.
So
if
we
did
the
opposite,
if
I
put
them
in
open,
Telemetry
I'd
have
to
like
do
a
compile
includes
into
the
API
and
then
when
the
API
makes
its
internals
visible
to
open
Telemetry
again
now,
there's
like
duplicate
conflicting,
so
so
for
the
nullables.
A
These
have
got
to
be
in
the
open,
telemetry.api
project,
I'm
convinced
there
is
a
second
issue
pertaining
to
this,
the
these
nullables
so
and
that's
the
the
number
two
there
open
telemetry.api
only
today
only
targets
standard,
2o
and
at
standard
462..
A
So
although
we
have
the
the
preprocessor,
the
you
know,
if
not
and
it's
standard
2-0,
you
know
don't
include
these
well,
because
API
only
has
the
2o
as
the
highest.
The
API
is
just
always
going
to
compile
with
those
internals,
and
so
those
internals
will
now
always
be
available
to
the
open
Telemetry
project.
So
one
of
the
conflicts
I
was
running
into
is
when
open
Telemetry
was
compiling
against
the
newer
Frameworks.
A
So
the
way
to
fix
this
was
to
add
knit
standard
2.1
to
the
API
project
and
I
could
see
I
linked
a
comment
there.
When
Blanche
was
working
on
this
and
the
open
Telemetry
project,
he
kind
of
lamented
that
he
had
to
add
the
newer
Frameworks
to
that,
but
it
was
necessary
for
a
similar
free,
compiler
trick,
so
I'm
doing
the
same
trick
and
then
I
just
kind
of
have
to
extend
it
to
the
API
project.
A
A
So
it's
not
it's
not
the
same
attributes,
there's
the
different
ones
in
each
file.
So,
like
the
part,
one
was
because
every
project
in
the
repo
is
going
to
need
access
to
these
nullable
attributes.
So
wherever
we
store
this,
it's
got
to
be
some
place
that
every
project
can
get
to
it
and
I've
been
working
ahead.
Trying
to
fix
some
nullables
in
the
API
project
in
the
API
project
is
going
to
need
some
of
these
extra
ones
that
are
in
this
other
project,
so
I
think
it
makes
sense.
B
Yeah
I
think
does
make
sense
to
move
them
to
some
like
lower
level
like
a
project
here,
which
is
the
API
project.
I
think
we
have
blanch
one
call
lunch.
Was
there
any
particular
reason
for
like
having
the
married
in
the
SDK.
E
E
Think
it's
a
big
deal
to
add
the
net
standard.
2-1
Target
to
API
I
have
an
idea
how
we
could
avoid
it,
but
personally
I
think
it
just
kind
of
happens.
You
know
as
newer
things
come
out
and
you
need
something.
Typically,
you
just
add
the
cargo
I,
don't
think,
there's
a
real
downside
to
it.
Does
anyone
else
feel
differently.
D
I,
don't
know
that
I
really
feel
any
differently.
I
I'm,
not
no,
no
big
concerns
or
red
flags
are
coming
to
my
mind,
but
just
like
exploring
other
ideas.
Maybe
what
if
things
like
this
were
just
in
a
shared
project
of
some
sort
and
we
just
like
compiled
included
them
where
they
needed
to
be
with
that?
E
So,
even
if
we
moved
all
these
files
to
a
shared
project
kind
of
like
how
we
have
a
different,
it
wouldn't
fix
the
necessary
necessarily
the
target
problem.
I
do
kind
of
like
what
we're
doing
in
contrib
I
think
it
might
be
a
little
cleaner
than
this.
So
we
could
do
both,
but
I
don't
know
if
it
would
help
specifically
with
the
targeting
thing.
D
D
Right,
you,
wouldn't
you,
wouldn't
ever,
have
any
of
this
like
problems
because
of
internals
visible
too.
If,
if
the
no
I
see
what
you're
saying
you
would
well.
E
D
Maybe
that's
something
to
test
off
I
mean
I,
don't
know
I
honestly,
like
I,
don't
I,
don't
know
offhand
or
recall
very
well
like
what
internals
visible
two
is
serving
Us
in
the
SDK
project,
with
like
saying,
internals
visible
too
from
the
API
I
think
that
might
be
worthwhile,
because
if
we,
if
it
turns
out
it's
all
these,
if
if
the
only
purpose
of
it
is
to
like
serve
these
kinds
of
needs-
and
we.
A
D
E
A
Okay,
I
I,
don't
mind.
I
can
take
another
day
and
just
kind
of
explore
that
and
see.
If
that
would
work,
I
didn't
fully
see
what
all
internals
were
being
like
utilized,
because
if
there's
anything
else,
that's
not
if
there's
something
like
core
critical
to
the
the
SDK
that
need
to
be
shared
internals,
then
maybe
that
won't
work
but
yeah
I
can
I
can
check
that
just
to
make
sure
just
to
just
to
explore
all
options.
D
B
Cool
yeah,
so
the
next
topic
is
from
vishwesh.
C
C
So,
while
working
on
that
I
try
to
remove
the
the
Frameworks
that
unsupported
one,
which
one
mainly
in
the
test
projects
like
net
core
3.1,
so
most
of
the
projects
don't
have.
It
now
accept
this
particular
case
that
it
came
in
last
week
where,
for
this
PR,
they
want
to
add
netco
app
3.1
for
testing
so
that
they
can
test
net
standard
Target,
which
is
there
in
the
library.
F
D
C
Them
so
there
will
be
no
like
no
test
running
against
net
standard
2.0.
So
I
wanted
to
see
what
what's
our
stand
on
this
one.
We
do
have
similar
thing
in
the
actual,
like
the
SDK
as
well,
where
we
are
targeting
that
standard,
but.
C
Have
redneck
6
pilot
framework,
so
we
are
not
really
testing
the
next
standard
one
and
we
do
have
that
open
issue
or
like
an
announcement
where
we
declare
that
we
are
not.
You
know,
testing
against
them,
but
since
this
particular
PR
is
actually
trying
to
add
an
unsupported
private
framework,
again
I
wanted
to
see
like
if
what
what
should
be
like
the
recommendation
here
from
our
side.
Is
it
okay
to
just
just
say
that,
like
don't
run
against
net
Center
2.0
or
like?
Is
there
a
better
way
to
handle
this.
B
That
ever
land
I
don't
think
so
much.
There
was
one
PR
that
we
did.
C
But
it
doesn't
really
Define
I
think
like
what
package
of
owners
will
do
about
the
target.
Frameworks.
C
Oh
I
see
I.
Think
I
saw
that
on
the
issue
itself,
because
if
you
could
go
to
on
the
issue.
E
Because
here's
here's
what
I'm
concerned
about
like
let's
say
this
goes
in
and
the
CI
might
work
today.
But
what
if,
like
GitHub,
removes
all
the
core
app
3.1
images,
and
now
we
can't
verify
this
code
anymore.
That's
kind
of
concern!
I
have
with
allowing
CI
for
stuff.
That
is
unsupported,
because
I
assume,
eventually,
we
won't
be
able
to
run
those
containers
or
whatever.
C
Yes,
that
that
makes
sense,
I
think
that's
reasonable,
like
I
have
seen
that
happening
before,
like
they
just
get
rid
of
the
older
versions
and
there's
no
way
for
you
to
run
the
unsupported
version
so
yeah.
So
basically,
like
I
mean,
should
we
just
say
that
you
know
the
next
standard
Duo
is
like
I
mean?
How
do
we
recommend
that
to
the
package
owners
we
are
doing
that
in
SDK.
Also,
so,
I
wanted
to
kind
of
include
that
as
well.
D
God
yeah
I
mean
first
and
foremost,
I
hate
it
I
hate
net
standard
but
testing
it
Mike.
Didn't
you
share
something
with
us
like
a
while
back
like
some
Ms
build
magic
that,
like
enabled
you
to
pull
a
specific
compiled
version
like
maybe
we
could
just
test
the
net
standard
20
package,
like
with
like
the
net
six
or
Net
7
Target
of
the
unit
test
project.
E
D
Yeah,
it's
probably
not
perfect,
but
yeah.
You
would
be.
You
know,
potentially
testing
different
code
paths,
different
logic
and
it
might
be
better
than
nothing.
F
E
C
That
is
probably
a
way
where
you
could
like
just
reference.
The
idea
learn
directory
instead
of
the
the
project.
C
B
And
it
also
is
also,
if,
like
our
core
components,
are
not
tested
for
net
standard,
2.0
and
concrete
components
are
depending
on
stuff
that
is
not
tested
for
net
standard
2.0.
Then
I,
guess
it's
it's
okay
for
us
to
tell
them
that
it's
like
it's
fine
to
just
leave
it
untested
and
like
have
your
tests
only
for
the
supported
Frameworks.
D
B
D
I
mean
the
other.
The
other
thing
that,
like
you
know
again,
like
I,
think
the
I
I
think
the
only
benefit
that
I
can
articulate
for
our
net
standard
targets.
Specifically
in
that
standard,
2-0
Target
is
you
know,
one
of
the
big
stories
of
net
standard
back
in
the
day
was
that
it
provides
this
bridge
for
people.
D
You
know
migrating
from.net
framework
to
at
the
time.net
core,
and
so
they
could
put
a
bunch
of
stuff
into
a
common
library
that
targeted
net
standard
and
it
could
be
shared
by
another
NET
Framework,
perhaps-
and
you
know,
I-
think
that
that's
still
a
thing
that
people
do
today-
I
mean
I,
guess
another
thing
that
might
work
from
a
unit
test.
D
Standpoint
right
would
be
to
like
have
like
a
the
a
test,
Library
project
that,
like
we
wrapped
the
functionality
that
we
wanted
to
test
and
we
referenced
the
net
standard
2o
like
SDK
or
whatever
component
from
and
then
the
actual
unit
test
project
referenced.
That
Library
I,
think
that
would
be
another
means
to
to
test
the
2-0.
C
Yeah,
that
is
like
one
issue,
at
least
in
the
instrumentation
libraries
we
we
have.
Some
preprocessors
so
like
like
we'll
have
to
make
sure
that
it
make
all
the
code
paths
work
correctly
in
case
of
net
standard
2
over
as
well.
So
so
right
now,
since
we
don't
test
it,
we
like
I,
think
we
just
say
that
it's
it's
not
tested
against.
It
may
fail,
but
there
is
no
like
promise
that,
like
we
will
do
anything
about
that.
If
I
understand
that,
like
open
discussion,
I'll
correct
me
if
I
want.
B
Surfaces
for
different
targets
and
run
times
I
mean
I,
feel
I
feel
like
if,
like
the
Uber,
SDK
and
API
itself
are
not
tested
for
this,
then
I
think
like
I,
think
we
do
mention
it
somewhere.
It's
not
this
one.
It's.
D
Yeah,
it's
it's
it.
It's
a
slightly
different
statement
in
the
sense
that
you
know
here
we're
basically
saying
like
hey.
You
know
we
don't
support
these
specific
Target
Frameworks,
but
that
statement
doesn't
really
say
we
don't
support
the
net
standard.
2-0
compilation
of
our
libraries
I
think
that's
a
slightly
different
statement.
D
C
C
It
is
good
like
confusing
so,
for
example,
right,
like
I'm
just
gonna,
take
an
example
of
the
instrumentation
Library,
where
that
issue
was
technically.
Customers
could
just
like
run
dotnet
core
2.1
app
and
they
they
refer
to
our
package.
C
But
then,
like
the
library,
there
will
be
no
errors
because
we
have
net
standard
Duo.
But
then
the
expectation
would
be
that
it
works
like
in
reality
like
we
don't
support
dot
net
core
2.1,
but
then,
like
the
the
argument,
could
be
I'm
using.net
standard
2.0,
so
that
that's
where
I
was
not
clear
like
how
do
we
differentiate
between
those
two
things?
C
F
C
Like
so,
basically,
I
have
an
asp
net
core
application,
the
same
as
statement
here
right,
like
I,
have
and
I'm
targeting
dot
net
core
app
3.1
in
my
ASP
net,
core
application
instrumentation,
which
will
not
give
me
any
compile
time
error
or
anything
like
that,
because
I
have
a
net
standard
Target
in
there.
C
If
someone
comes
in
and
says
that
I
am
using
this
would
that
be
still
considered
as
supported,
because
ultimately
they
are
running
unsupported
framework.
They
are
not
like
running
it
in
some
net
standard
Library,
they
are
like
running
it
on
unsupported.net,
core
framework.
D
D
D
We
do
support.net
framework
462
right
and
they
are
getting
our
net
standard
build
and
if
they
highlight
the
same
bug,
it's
like
a
slightly
different
fact
pattern,
but
I,
maybe
the
same
bug.
F
B
B
But
yeah
I
do
think
this
is
like
having
this
intermediate
Library
like
this
approach,
is
much
cleaner
than
like
the
other
alternative
of
like
picking
up
a
binary
space
selectively
during
run
time
or
like
whatever
the
hack
unit
test
hack.
We
were
considering.
D
And
I
guess:
I
guess
a
third
one
third
option
right,
which
you
know
I
don't
like,
but
just
put
it
out
there
is.
We
could
just
have
a
policy
that
we
keep
our
support
policy
the
same,
but
we
have
our
unit
tests
run
against
the
last
out
of
support
version,
of.net
right
and
like
it
always
pulls.
F
D
C
That
shared
one
probably
will
need
two
different
test
projects
right,
I'm
I'm,
not
wrong
the
thing
that
will
probably
need
like
doing
that.
Learning
the
same
test
on
two
different
projects,
because
I'm
I'm,
just
thinking
like
it
could
be
one
project
but
I-
think
one
project
will
refer
to
our
the
the
normal
way
that
we
are
doing
right
now
and
the
another
one
will
just
prefer.
The
net
standard
to
O,
which
will
bring
in
the
next
standard
Duo
Library.
B
Yeah
I
think
you
need
like
one
extra
project
for
the
intermediate
library,
then
another
test
project
to
refer
to
that
one
I
think
like
we
should
be
able
to
tell
them
to
do
something
similar
to
what
we're
doing
in
the
SDK
project.
B
Main
project
like
have
them
like
just
tell
them
that
if
they
can
also,
if
they
are
targeting
that
standard
2.0,
then
they
should
be
fixing
bugs
that
are
reported
just
exclusively
for
net
standard
2.0,
but
like
just
the
testing
part
of
it,
they
can
like
if
the
main
project
is
okay,
comfortable
with
the
way
things
are
right
now,
I
think
they
should
be
able
to
do
that
as
well,
and
it's
just
that
if
yeah
I
mean
I,
get
that
part
of
that
stuff
to
tell
like
they're,
not
testing
it,
but
then
I
think
I,
like
Michael's
idea,
where
he
was
telling
that
they
should
be
running.
B
E
Well,
I
think
I
was
thinking,
they'd
have
like
their
own,
like
pipeline,
defined
or
whatever
you
call
it
action,
but
it
could
be
external
I.
Just
I,
don't
know
how
that
would
work.
Basically
I
the
messaging
was.
If
you
want
to
do
an
unsupported
thing,
then
you
have
to
figure
out
how
to
make
it
work
and
then
support
it
from
there
so
that
if
it
suddenly
broke
it
wouldn't
block
like
the
rest
of
the
repo,
we
could
still
release
other
components
and
just
that
thing
that
needed
the
old,
unsupported
run
time
would
be
broken.
E
C
C
F
E
D
I
haven't
dealt
with
the
contribute
bone
a
long
time,
but
you
know,
like
you,
Relic
used
to
have
an
exporter
and
I
did
a
little
bit
of
work
on
that
a
while
back
and
if
I
recall
the
the
CI.
Whenever
I
did
submit
a
PR,
the
CI
did
run
against,
like
all
the
other
components
took
a
long
time.
But
again
that
was
a
while
ago.
So
maybe
maybe
they've
improved
that
or
done
something
different.
C
All
right,
I
think
we
can
check
that
out
and
see.
Do
you
have
something
better?
So
basically
we're
saying
like
we'll
just
separate
out
the
the
build
pipelines
for
all
the
packages
right.
F
D
B
B
Well,
I
think
we
have
quite
a
few
more
items
on
the
agenda,
so
this
one
like
Alan
I,
wanted
to
ask
you.
Do
you
think
we
want
to
do
any
Alpha
2
version
release
soon
like
this
week
or
next
I
do.
D
I
do
want
to
do
that
this
week
if
people
are
open
to
it,
I
already
found
a
bug:
I
need
to
submit
a
new
PR,
it's
a
small
thing
or.
F
B
D
And
so,
if
we
do
that
this
week,
early
next
I
guess,
the
question
is:
if
there's
anything
else,
that
other
folks
would
want.
B
B
Unless
somebody
wants
to
plants,
do
you
want
to
do
this
one
in
the
next
Alpha
I
think
you
also
have
this
on
the
agenda.
E
Yeah
on
the
bottom
there,
it
doesn't
matter
to
me
if
it
gets
in
the
next
Alpha
I'm,
just
asking
everyone
in
Wonderland
at
all
I
think
it
would
be
kind
of
cool
to
do.
I
remembered
this
because
we
ran
into
it
with
one
of
the
exporters
we
were
just
working
on,
like
Azure,
monitor
or
something
every
exporter
we
do
has
to
deal
with
this
weird
State
versus
State
values
thing.
So
it's
just
kind
of
pushing
the
mess
further
further
down
the
chain.
E
So
originally
I
had
tied
this
to
the
big
logging
changes
and
I
thought.
I
would
just
do
them
together
in
like
1.6,
but
it
occurred
to
me
they're
not
really
related,
like
we
could
do
this
stuff
and
clean
up
that
mess.
It
doesn't
really
need
any
of
that
spec
stuff,
they're,
more
or
less
completely
unrelated,
so
I
thought
I
would
throw
this
up
and
see
what
people
think
about
getting
it
into
1.5.
B
Yeah
I
think
Allen
has
been
reviewing
this,
but
I
haven't
gotten
the
chance
I
haven't
seen
today.
I
was
only
looking
at
it
today.
Just
the
description
part
of
it
I
think
I'll
get
some
time
this
week,
but
yeah
I
think
it
should
be
good
to
go
for
1.5.
B
E
B
D
Yeah
I
like
what
this
PR
is
doing,
the
just
a
couple
questions
that
I
had
was
I,
mainly
just
about
the
new
options
that
you
included.
I'm
not
strongly
opposed
to
him,
but
you
know.
D
C
B
B
D
D
B
I
haven't
checked
with
him
about
that,
but
I
yeah
I
mean
at
last
I
spoke
to
him.
It
didn't,
he
didn't,
seem
super
positive
on
it
getting
stable
and
like,
maybe
not
even
by
one
dot,
maybe
not
even
by
June
2nd.
The
date
we
have
said
we
might
have
to
yeah
see
if
we
want
to
like
just
move
it
out
of
the
stable
release
and
like
put
it
back
in,
but.
B
Okay,
so
yeah
I
will
also
take
a
look
at
this
PR
and
if
anyone
has
any
items
that
they
would
like
to
get
added
for
Alpha
2,
then
please
like
either
just
like
yeah.
F
F
B
I
had
also
put
this
item,
assign
owners
for
1.1.5.,
open
items,
so
I
think
we
have
now
owners
for
like
most
of
the
stuff.
This
is
assigned
to
see
Joe.
B
C
Reminder
to
review
that
one
I
think
I
Incorporated
all
the
feedback
from
what
we
discussed
last
week.
Yeah.
Let
me
know
if
there's
anything
else
or
something
doesn't
look
right
now,
so.
C
Is
there
are
a
couple
of
them
which
are
defined
in
that
issue
itself?
An
issue
like
I
was
just
trying
to
get
those
ones
in
first
and
then,
once
we
have
the
structure
and
I
think
you
should
be
able
to
add
more
as
we
need
like
this.
C
F
C
Them
are
like
the
batch
export
processor
number.
F
C
Metrics
dropped
instruments
active
stuff
like
that,
so
I
think
I
think
the
next
one
I
like
if
this
one
is
more
than
I,
think
next,
one
I'll
look
for
the
the
measurement
dropped
one
and
also
the
instruments
one
as
well,
so
we'll
try
to
touch
upon
the
metric
side
as
well.
F
D
I
I
actually
meant
to
put
a
note
on
this.
I
had
a
conversation,
a
number
of
weeks
back
with
sijo
regarding
this
and
there's
a
sense
that
we,
oh,
he
doesn't
really
want
to
do.
This
I
think
it's
the
right
thing
to
do
in
terms
of
like
correctness
with
the
spec.
It
definitely
does
have
performance
implications.
D
More
activities
are
created.
You
know,
activities
are
expensive
from
a
garbage
collection
standpoint.
D
My
my
gut
says
that
this
like
to
really
solve
this
problem
in
a
performant
way.
It's
probably
maybe
more
of
a.net
team
or
they
select.
The
runtime
should
be
solved
within
the
runtime
repo.
D
One
idea
that
CJ
tossed
out
was
like
you
know
we
could
introduce
some
configuration.
You
know
like
we
basically
have
like
a
the
default.
Behavior
is
just
this
bugged
Behavior,
but
then
we
had
a
a
configuration
that
aligns
the
behavior
with
the
spec,
and
people
can
turn
that
on.
If
it's
really
important
to
them,
I
was
going
to
write
that
up.
D
I
should
just
write
that
up
on
this
issue
and
like
solicit
some
more
feedback
from
the
community
based
off
of
this,
and
maybe
that'll
help
inform
n
a
yay
or
nay
whether
this
is
a
one,
five
thing
or
you
know
something
else.
D
If
you,
the
pr,
is
probably
closed
now,
but
if
you
scroll
down
there's,
probably
a
link
in
here
somewhere
to
yeah.
That
fix
is.
D
D
Returns,
what
is
it
activity
sampling
result,
none
anymore,
except
in
the
suppressed
instrumentation
case,
but
it
always
returns
propagation
data
which
we'll
always
create
cause
an
activity
to
be
created.
D
E
D
A
B
D
Yeah
I
mean
the
behavior
is
not
right,
I
mean
it.
It's
also
like
the
the
thing
that
I
think
is
going
to
become
maybe
or
might
cause
more
years
of.
Your
feedback
is
specifically
with
exemplars
and
with
logs
in
that
you
know,
part
of
open
telemetry's
design
is
that
things
things
can
be
correlated
to
trace
data
exemplars
and
logs,
and
it
may
be
correlated
to
you
know
spans
within
a
trace
that
happened,
but
weren't.
D
So
what
this
our
current
behavior
is
right,
is
that,
like
any
exemplars
or
logs,
that
we
record
are
only
ever
going
to
be
correlated
to
a
span
that
actually
was
also
sampled
and
then,
like
it,
I
guess
it
might
conceivably
like
cause
some
confusion
like
if
I'm
looking
at
my
code
and
I,
see
a
log
message
inside
the
scope
of
a
of
a
span
that
I'm
not
sampling,
right
and
then
I.
Compare
that
to
what
I
see
in
my
back
end
and
I
see
that
that
log
message
is
not
correlated
to
that
span.
D
F
D
B
B
Makes
sense,
I
mean
I'm,
not
sure,
if
I'm
understanding
it
correct
but
like
if
it's
exemplars
or
logs
and
like
we
are
always
creating
an
activity,
but
even
if
it's
not
recorded
and
I,
think
the
way,
at
least
for
example,
as
I
would
assume
that
you
see
some
metrics
spiking
up
or
like
going
down.
And
then
you
try
to
find
the
details
of
this
man
to
try
to
understand
like
what
could
have
caused
it
or
like
what
was
going
on.
But
if
that
span
itself
is
not
recorded,
then
like.
How
much
does
it
help
like?
D
Help
somebody
I,
don't
know
I
mean
the
the
you
can.
You
can
dig
deeper
into
the
context
that,
from
that
issue
that
Christian
opened
up,
he
links
to
the
conversation
and
the
spec,
which
it
was
an
old
one.
I
mean
it
took
place
in.
D
B
D
Christian
will
probably
chime
in
you
know,
and
that
may
influence
our
thinking
or
prioritization
or
what
we
want
to
do
here.
B
D
D
B
Because
we
are
asserting
that
we
need
like
a
we
need
a
valid
trayside
span,
ID,
okay
side.
You,
like
a
good
context,
span
context.
B
I'm
kind
of
I
I
haven't
really
looked
into
the
shim
school
at
all,
so
I
don't
know
like
what
like
why
we
we're
throwing
an
exception
here.
C
D
If
we're
not
gonna
land
that
PR,
then
maybe
there's
something
that
we
should
do
here.
If
in
fact,
they're
getting
an
exception,
I
don't
know,
but
I,
don't
know
enough.
B
B
B
Yeah
there's
one
more
item
that
I
want
to
discuss:
I
think
in
only
two
minutes
over
and
Lance
is
left
but
Alan.
If
you're
around
I
can
ask
you
real
quickly,
I
think
all
the
other
items
have
as
people
assigned
this
one
and
we're
going
to
discuss
more
or
more
about
it,
but
open
telemetry.net
SDK
is
not
aod.
Safe,
I
thought
Blanche
would
have
known
for
sure
I
I.
Do
you
know
if,
like
what
kind
of
work
is
involved
for
this,
like
we
can.
D
I'm
afraid
I,
don't
yeah
all
I'm
aware
of
is
that
there
are
things
that
aren't
aot
friendly,
but
I
haven't
really
studied
them.
B
B
D
B
B
There's
another
topic:
I
think
we
can
discuss
it
later,
though,
like
maybe
next
week.
This
would
take
some
time.
B
I
added
this.
It's
about
like
supporting
asp.net
core
on
NET,
Framework
runtimes,
but
I
think
some
more
some
more
time
to
discuss.