►
From YouTube: 2022-10-12 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
A
Thing
that
you
had
asked
about
recently
that
I
was
actually
thinking
about
bringing
up
the
day
in
today's
meeting.
I
don't
know
if
it
was
ultimately
useful
to
to
your
situation,
but
you
were
asking
about
something
like
sampling
out
spans
or
something
to
a
certain
endpoint.
A
And
I
noted
that
the
like
the
HTTP
conventions,
for
example,
presumably
require
that
HTTP
spans
be
created
with
route
or
Target
attributes,
so
that
a
sampler
so
that
the
sampler
is
provided
with
those
attributes
and
can
make
decisions
based
off
of
that.
That's
not
something!
That's
possible
in.net
today,
but
I
wanted
to
get
the
folks
on
this
call
when
they,
when
they
show
up
their
their
thoughts
and
opinions
about
the
best
way
to
do
that
because
I
don't
know
foreign
that
I
was
able
to
think.
B
I
think
we
were
talking
about
it
in
the
that
working
group
reading,
whatever
that
was
called
yeah
yeah,
hey.
C
Yeah
it's
just
previous
weeks
one
and
it
seemed
to
put
me
into
the
right
one.
Foreign.
A
C
E
C
C
A
C
A
C
But
I
think
the
meeting
notes
have
link
to
the
invite
as
well
I
mean
the
assuming
as
well.
So
that
way
we
should
be
still
fine,
because
it's
only
like
two,
oh
no
do
we.
No.
Actually,
we
didn't
put
the
actual
link
into
the
meeting
notes.
It
just
says
pick
it
from
the
calendar.
C
C
C
E
So
yeah
one
was
the
net
standard,
keeping
the
net
standard
proposal
that
we
talked
about
last
three
meeting
as
well.
We
wanted
to
see
if
the
contents
look
fine.
E
C
E
Found
it
like
good
enough,
I
mean
I
have
approved
the
pr
I.
Think
cgo
has
left
a
few
comments.
A
A
We
can
put
this
announcement
out
and
then
Circle
back,
but
I'd
still
like
to
think
about
whether
there's
a
different
way
we
can
handle
that
HTTP
client
fix
from
a
while
back,
because
I
think
it
would
be
a
good
idea
to
reinstate
the
the
net
standard
targets
to
the
instrumentation
that
we've
already
dropped
it
from,
but
I
guess
that's
the
first
question:
do
other
people
feel
that
way
or
other
people
thinking
that
you
just
want
to
leave
it,
as
is.
D
I
think
we
should
put
them
back,
but
in
the
case
of
HTTP
clients
we
should
do
net
four
six,
two.
What
are
we
on
net
standard
20
and
then
that's
standard
2-1
with
net
six,
because
I
think
adding
the
tube
one
where
it
was
missing
before
we
can
fix
that
issue
where
if
you
had
a
net
stand
or
2o
and
you
consumed
it
into,
you
know
a
net
core
or
something
you
would
blow
up.
If
you
add
that
standard
to
one
I
think
it
will
smooth
that
out.
That
makes
sense.
A
D
It
was
you
have
to
have
a
library
in
the
middle,
so
you
have
our
instrumentation
consumed
into
a
project
which
only
targets
net
standard
2-0,
and
then
you
consume
that
into
like
net
six,
so
it'll
have
it'll
use
the
2-0
bindings
and
then
it
will
blow
up.
But
if
you
introduce
that
2-1
in
the
chain,
it
can
flow
correctly.
D
C
C
Okay,
so
we
still
expect
the
shared
Library
owners
to
do
some
update.
Yes,.
D
C
So
if
with
their
shared
Library
using
it
472
and
it's
10
day
2.1,
it
would
bind
to
either
net462
or
next
standard
2.1
of
the
instrumentation
and
depending
on
the
final
application.
If
it's
tolerant
framework,
it
will
always
pick
the
net
for
six
to
one
okay,
yep
yeah.
That
sounds
like
a
good
idea:
okay,.
C
So,
what's
the
reasoning
behind
adding
it
back
to
HTTP
client,
but
not
for
SP
net
core,
it's
the
right
like
we're,
not
proposing
to
add
it
back
to
SP
net
core
right.
We
are
only
going
to
keep
net
60
and
future
version
of
it.
A
Now
I
was
actually
I
mean
now
I
was
tossing
out.
My
proposal
was,
to
also
add
it
back
to
asp.net
core
yeah
I,
see.
C
But
that's
a
separate
question:
oh
yeah
spinet
core
might
be
because
there
is
an
open
PR,
which
I
think
is
right.
Now
there,
where
we
are
taking
a
dependency
where
we
are
changing
the
enrich
signature
to
use
the
stripe.
I
don't
know
if
that
would
be
feasible.
If
we
have
net
standard,
because
in
that
standard
we
may
have
to
fall
back
to
the
object.
That's.
F
Already
a
change
I
have
merged
before,
let's
remove
the
reflection
part,
since
we
got
rid
of
the
net
standard,
so
I
think
we'll
have
to
reward
that
back
as
well
or
handle
it
accordingly.
C
Instagram
yeah,
because
with
that
standard
2
we
don't
have
I
mean
it
won't,
be
a
problem
for
HTTP
client,
but
it
would
be
a
problem
for
sp-net
core
because
we
need
to
consume
the
SP
net
core
packages.
A
F
A
A
C
C
A
And
that's
fine
I
mean
if
we
want
to
continue
to
take
that
stance.
I
guess
this
is
just
that
I
guess.
The
first
probably
sign
that
we've
seen
where
somebody
is
kind
of
poking
at
this
and
I
guess
I'll
be
interested
to
know
whether
this
continues
to
come
up,
especially
after
the
140
release.
If
we
have
dropped
net
standard
from
anything.
C
C
Be
sure
it's
like
you've
been
simply
you
do
that
we
are
like,
which
is
also
the
next
topic
we
can
see.
If
the
classes
we
need
are
publicly
exposed
in
these
packages
yeah,
it
should
be
pretty
sure
they
should
work.
A
I
think
we
should
just
so
that's
a
good
question.
My
stab
at
the
The
Proposal
would
be
to
just
reintroduce
the
net
standard
targets,
knowing
that
and
I
think
this
is
actually
I.
Think
I
said
this
some
in
some
way
in
the
announcement,
knowing
that,
as
we
drop
framework,
specific
targets,
a
potential
consequence
of
that
is
that
functionality,
or
maybe
performance
improvements
or
whatever
that
existed
within
the
framework.
Target
specific
compilation,
maybe
lost
in
as.
A
A
E
Okay,
yeah
I
think
so
we
know
what
to
do
now.
C
F
Well,
yeah
sure
I'll
just
try
to
First
bring
back
the
net
standard
first
see
if
there
are
any
issues
along
with
these
packages,
because
I
have
already
made
changes,
removing
the
reflection
so
first
that
would
be
the
test.
F
So
for
this
one,
just
along
the
same
lines
that
we
are
talking
about,
like
so
for
a
spinner
core
I'll,
be
making
some
changes
to
to
get
rid
of
reflection
and
then
any
generic
types
that
we
use
like
right
now
for
the
enrich
callback.
We
pass
in
three
parameters,
which
is
the
the
HTTP
request,
response
or
exception
what
kind
of
callback
it
is
like?
There
is
a
name
of
the
event
and
I
think
the
third
one
is
active.
F
The
third
one
is
activity,
so
so
as
an
improvement
and
then
like
when,
whenever
the
enrich
callback
is
used
by
customers,
they
have
to
first
check
what
kind
of
event
it
is
and
then
they
also
have
to
do
some
typecasting,
because
we
are
passing
in
an
object
there.
So
to
get
rid
of
that,
I
I
introduce
three
different
enrich
callbacks,
based
on
when
it
is
called
So.
Currently
we
just
we
have
three
in
future.
F
We
might
have
more
based
on
like
if
we
wanted
to
enrich
on
custom
or
something
like
that,
then
we
may
need
to
add
more
in
there,
but
for
now
we
I
I
just
basically
included
the
ones
that
we
we
do
have
in
the
code,
so
so
I'm
introducing
three
new
ones
and
rich
on
start
and
rich
on,
stop
and
then
Rich
on
exception.
F
So
the
the
question
here
is
like
did
the
naming
like
what
would
be
the
good
name
which
is
like
possibly
like
self-explanatory?
And
customers
will
have
easier
time
to
easy
time
to
understand
it
and
like
they
don't
have
to
like
read
through
what
it
exactly
means.
F
So
I
think
siju
had
some
suggestion
and
then
I
also
had
like
an
alternative,
so
just
wanted
to
kind
of
bring
this
up
here,
see
what
what
would
be
the
if,
if
any
of
these
options
sounds
good
to
the
folks
here,
so
I
think
she
just
suggested,
enrich
from
HTTP
request
and,
like
the
other,
one
will
be
enriched
from
HTTP
response
and
then
the
third
one
will
be
enriched
from
exception.
Okay,
just
exception
yeah.
F
Now
that
will
be
a
little
bit
different
from
what
customers
are
used
to
right
now,
because
they
know
that
the
like
they
are
already
checking
the
event
names
as
onstart
activity
on
stop
and
on
exception,
the
the
names
that
we
pass
in
so
I
suggested
an
alternate
which
is
in
my
last
comment.
So
that
would
be
enrich
on
request
start
request,
open
request,
exception
so
like
which,
which
one
of
these
options
sounds
more
easy
to
understand.
Then
usable.
So
just
just
want
to
bring
this
up
here.
A
A
F
So
there
are
two
of
them
right
now
that
I
know
often
like
that
those
are
the
ones
that
we
are
subscribing
to
so
like
I
think
there
is
one
hosting
dot
exception
and
another
one
is
Diagnostics
dot
exception.
F
I
think
it
depends
like
where
the
exact
exception
is
coming
from,
but
they're
like
two
of
those
right
now
that
we
we
are
subscribing
to
like.
If,
if
there
are
more,
we
need
to
include
I
think
we
should
include
them
here.
It
should
be
in
the
HTTP
in
listener.
In.
F
Not
because
we
like,
we
don't
have
the
we
don't,
handle
those
exceptions
differently,
we
we
are
just
extracting
the
exception,
objects
from
all
of
them.
C
C
Yeah
the
start
and
stop
seems
in
Duty
like
it
only
occurs
once
stop
occurs
once
and
exception.
I
think
we'll
need
to
just
confirm,
because
if
we
give
a
name
then,
if
you
have
another
exception,
then
we
need
to
give
it
a
different
name.
C
Yeah
that
would
be
like
a
like
basic
test.
We
should
make
sure
like.
We
should
only
be
coding
it
exactly
once,
but
that
should
be
the
case
if
you
are
getting
a
single
callback
from
the
SP
net
code
itself,
so
they
get
one
call
back
on
start
stop,
and
then
we
get
another
callback.
If
it's
an
embassy
that
we
do
for
enriching
the
display
name
and
some
stuff,
then
potentially
one
of
the
exceptions
from
hosting
our
Diagnostics,
and
we
intend
to
expose
three
of
them
to
customers.
C
The
start
stop
and
exception
MVC,
like
potentially
in
a
different.
Maybe
we
will
have
to
decide
whether
we
need
to
expose
that
at
all
I
think
most
likely,
not
precurate,
but.
C
That
would
be
a
better
name
than
just
exception,
because,
because
we
initially
were
looking
at
handheld
as
well,
that
was
epic,
so
yeah.
This
would
make
it
even
clearer.
C
C
C
C
Yeah
overall,
like
we
all
agree
that
we
need
to
make
the
strong
type
API,
then
just
object
and
asking
user
to
cast
right.
A
C
C
Okay:
okay,
it's
context:
okay
and
for
HTTP
client
and
the
trpc
one
I
mean
I
didn't
mean
to
like
need
to
do
it
all
in
one
PR.
But
when
we
do
the
next
release,
it
should
contain
all
the
breaking
changes
in
One
release.
So
people
find
it
okay,
pain
and
just
suffer
it
once
that's
supposed
to
continue.
It
releases
it
more
and
more
Breaking
Chains.
F
So
for
HTTP
client
one
since
yeah,
we
will
have
to
do
some
checking
to
see
like
if,
if
we
bring
back
the
net
standard,
one
then
I'm
not.
C
C
C
B
No
I,
don't
think
it'll
be
too
bad.
I
also
think
that
I'm,
just
like
looking
at
some
of
our
code
now
and
I,
don't
think
people
are
even
necessarily
like
using
the
event
name
so
like
it's,
probably
just
applying
the
same
logic
like
multiple
times
so
in
that
regard,
like
I
think
this
is
a
good
change.
A
B
C
I
have
to
believe
now,
so
if
there
is
anything
else,
you
need
just
ping
me
after
the
meeting.
Thank
you.
E
E
Okay,
I
think
Blanche
is
going
to
put
his
name
suggestions
there
and
then
we'll
comment
on
the
pr
I
guess.
E
F
But
we
don't
have
enrich
on.
We.
F
I
mean
we
don't
have
it
right
now,
maybe
that
that
is
one
of
the
things
that
I
think
we
somewhere
I've,
seen
like
think
an
issue
where
customer
was
requesting
it,
but
yeah
I
think
that's
the
separate
discussion,
I
guess
whether
we
should
add
it
or
not.
Okay,.
E
F
Yeah
for
the
SQL
one,
we
have
an
enrich
I,
think
for
SQL.
We
just
have
like
on
custom.
A
single,
even
I,
have
to
see
I
I,
don't
recall
like
how
it
looks
exactly
I'll.
Take
a
look
at
that.
One.
E
E
Okay
and
in
the
Handler,
we
are
calling
that.
F
Yeah
yeah
and
like,
although
it
is
defined
for
both.net
framework
and
dotnet
core,
but
I,
think
we
are
only
doing
it
in.net
core.
This
is
something
that
I
found
yesterday.
E
E
Okay,
yeah
I
think
if
there's
something
that
needs
custom,
maybe
we
should.
We
will
just
create
a
new
language
for
custom
and
then
like
have
it
all
together
at
once
like
have
it
all
shipped
out
at
once,
I
think.
A
Last
week
we
talked
about
getting
in
the
min
max
and
I
feel
like.
There
was
something
else,
and
then
that
was
going
to
be
the
scope
for
the
next
release
do
do
you
all
think
that
this
this
enriched
work
is
going
to
be
added
to
the
scope
before
we
release
again.
E
I
guess
if
like,
if
we
get
done
with
min
max,
we
can
have
a
release
and
then
because,
when
we
are
shipping
enrich,
we
want
to
do
it
for
all
the
possible
instrumentation
libraries
right
all
the
instrumentation
libraries
that
have
an
enriched
functionality.
We
want
to
ship
them
all
together,
so
it's
so
like,
if
all
of
that
would
have
to
be
done
before
a
release
like
if
it
takes
time,
I
guess
and
we
have
min
max
study.
Maybe
we
could
do
beta
2
with
min
max.
A
A
E
A
I
think
we've
talked
about
this
before
scroll
down
it's
near
here,
just
a
little
bit
further
yeah
here
stop
there
so
that
sentence
right
there.
That
starts
following
attributes.
Most
people,
provided
it
span
creation
time.
So
the
idea
being
that
you
know
you
could
write
a
custom
sampler
and
it
could
use
that
information
to
make
its
sampling
decision.
That's
not
something!
That's
currently
possible
with.net,
because
none
of
our
instrumentation
adds
that
I
know.
A
We
have
different
ways
of
maybe
achieving
a
similar
thing
like
the
filter
mechanism,
with
with
asp.net
core
instrumentation,
for
example.
But
more
general
question
do
any
of
you
particularly
Microsoft
folks.
Are
you
aware
of
whether
this
is
something
that
may
be
considered
by
the
asp.net
core
team
at
some
point
in
time?
Because
now
that,
like
with
Net
7
they're,
creating
the
activity.
A
A
It's
not
a
pressing
thing.
It's
just
I
I
stumbled
upon
this
again
today
and
I
was
like
yeah.
That's
something
I
mean
it's
a
must
whatever
in
in
Spec
terms,
something
we
just
can't.
We
can't
do
today
and
actually
has
become
a
little
bit
more
difficult,
I.
Think
now
that
the
activity
is
not
being
created
by
our
instrumentation.
E
A
A
And
then,
maybe
more
specifically
like
how
would
any
of
you
recommend
somebody
who
wants
to
effectively
sample
out
or
not
sample
spans?
For,
like
say
a
health
check
endpoint
for.
A
E
C
A
Other
thing
that
had
come
to
my
mind
was
like
wrapping
an
exporter
and
then,
of
course,
at
that
point
in
time
you
know
you've,
you've
created
this
band,
you're
potentially
done
a
whole
bunch
of
work
with
the
span
and
then
just
drop
it
on
the
floor.
So
that
would
be
the
least
efficient
of
the
solutions,
but.
B
What
what
do
you
sketch
that
that
I,
I
guess
have
is
like
say,
I?
Have
a
web
API
of
some
kind
and
I
I
always
want
like
the
spam
that
has
like
the
span
kind
of
server,
but
I
want
the
internal
spans
like
I,
don't
want
to
create,
like
n
number
of
internal
spans
on
every
request.
I
just
want
them
like
some
of
the
time,
because
it
it
informs
me
about
how
my
endpoint
is
executing,
but
it
doesn't
like
overwhelm
in
terms
of
the
number
of
spans
that
get
created
like
I
feel
like
that.
B
B
The
use
case
would
be
that
I
want
them.
Some
of
the
time.
Okay,
like
like,
like
basically
sampling
the
requests
in
sampling,
the
internal
spans
at
like
a
different
rate,
and
maybe
that
kind
of
violates
the
spec
I'm,
not
sure,
but.
E
Yeah
I,
don't
know,
I
think
if
it's
the
same
process,
maybe
if
you
have
multiple
Tracer
provided
sdks,
they
can
each
have
their
own
set
of
activity,
sources
that
they're
listening
to
and
their
own
sampling,
but
otherwise
the
whole.
If
you
set
a
sampler,
it
is
applied
at
the
Tracer
provider
level.
So
anything
that
is
listening
to
and
exporting
like
anything,
that's
listening
to
will
be
using
the
same
sampling
logic.
E
A
This
might
be
a
little
bit
of
a
tangent,
but
I
think
the
idea
of
multiple
Tracer
providers
might
get
Messy
as
well,
just
because
each
Tracer
provider
would
instantiate
its
own
activity
listener
and
at
the
end
of
the
day,
only
one
activity
is
is
generated,
and
so
wouldn't
the
the
two
distinct
pipelines
that
are
set
up
basically
be
doing
work
on
one
activity.
E
E
Rework
like
duplicate
work,
probably
not
necessarily
depends
like
maybe
one
is
having
its
own
set
of
process
or
the
other
one,
as
it
has
its
own
processors
and
exports,
but
I
think
it
like
depends
very
much
on
the
specific
use
case,
like
it's
tough,
to
just
make
a
recommendation
like
that
for
a
general
scenario
like
without
knowing
the
specifics
but
yeah,
we
could
get
into
issues
where
you
have
multiple
Tracer
providers.
In
there
you
have
multiple
activity,
listeners,
try
and
listen
to
the
same
activity
and
work
on
it.
A
B
I
think
they're
more
than
one
use
case
that
I'm
interested
in,
but
yes
that
would
that
would
be
one
of
them
like
the
multiple
provider
route.
B
I
think
is
okay
like
if
I'm
very
careful,
so
that
the
sources
that
get
routed
to
each
pipeliner,
you
know
completely
separate
like
if
I
you
know,
if
I
just
listen
to
Source
a
with
provider,
one
and
B
with
provider,
two
like
I
think
I
would
be
okay
from
that
perspective,
but
we
yeah
we
have
the
we
have
sort
of
the
the
the
the
way
you
just
described
that
yes,
but
it's
also
like
this
is
not
an
asp.net
or
thing
but,
like
you
know,
I
have
some
console
app,
that's
running
and
it
does
a
lot
of
span
a,
but
very
few
span
B
and
if
I
have
a
really
low
sample.
B
You
know
that
I
don't
get
enough
information
about
B.
So
it's
like
it's
like
understanding,
like
all
the
controls
in
place
that
allow
me
to
like
get
the
right
data
that
I
need
like,
depending
on
my
scenario,.
B
E
E
A
Know
the
trace
context,
it
does
have
the
kind
yeah.
B
B
B
You
know
like
going
against
like
the
the
parent
sampling
decision,
like
you
know,
if
I
use
parent-based
sampler,
which
is
like
pretty
common
but
underneath
conditions
I
want
to,
like
you
know,
override
that,
because
I
have
a
particular
use
case
that
generates
too
much
data
and
I
want
to
reduce
it,
etc,
etc.
So
I
think
there's
like
a
lot
of.
E
Yeah
you
should
be
able
to
like
need
your
own
sample,
sampler
override
the
shoot,
sample,
method
and
I
mean
if
it's
as
straightforward,
like
if,
if
kind
works
like
very
simply
like,
if
it,
if
it
works
for
you,
then
you
can
do
that
in
a
simple
way.
Your
own
custom,
sampler
and
I
would
believe.
That
would
be
the
best
way
to
do
it.
Instead
of
like
going
to
increase
the
provider
approach
or
even
yeah,.
D
A
Yeah
implementing
your
own
sampler
is
definitely
not
wrong.
You
know
totally
depends
on
your
use
case.
Just
one
last
note,
the
the
parent
pay
sampler
has
some
kind
of
some
of
its
own
extensibility
in
the
sense
that
the
way
that
it
gets
constructed
you
can,
you
can
pass
it
for
different
Samplers
for
the
four
different
scenarios,
which
are
right
there
on
line
51
and
Below.
You
know
so
when
remote
parent
is
sampled,
then
you
can
configure
all
those
default
is
on.
A
But
if
you
scroll
down
there's
another
Constructor
for
this,
that
basically
says
like
hey
under
this
scenario:
remote
parent
sample
I
want
you
to
use
this
other
sampler,
so
you
can
get
pretty
nutty
with
the
parent-based
sampler
alone.
If
again,
if
these
are
the
right
hooks
for
whatever
your
use
case
requires.
A
Yeah,
it's
more
of
a
curiosity,
I
think
it's
also
come
up
in
an
issue
before
maybe
I
seem
to
have
a
vague
memory
of
that.
A
So
I
suspect
folks
will
at
some
point
hope
for
this
from.net,
just
because
other
languages,
I'm
sure,
are
already
doing
this.
Just
our
world's
a
little
bit
trickier
in
this
regard,
so
yeah
well,
I'm
curious.
B
I
have
one
other
random
question,
just
throw
a
link
in
the
chat,
so
I
opened
this
issue
in
the
spec
repository,
because
I
noticed
that
the
HTTP
status
code
type
is
different
depending
on
if
you're,
using
tracing
or
metrics
in.net
and
I
I
think
the
Spec's
probably
just
wrong,
but
I'm
curious
like
what
the
process
is
for,
like
this
kind
of
thing,
like
the
someone
makes
a
change
to
the
specification
and
then
they
notify
all
the
sdks
to
go
and
make
a
change
or
what?
What
is
that?
Typically
look
like.
A
I,
don't
think
there's
a
great
process
around
that
today,
particularly
for
like
a
small
change
like
this.
A
A
Things
for
so,
for
instance,
I
think
Jack
who's
been
working
pretty
heavily
with
the
logging
Sig
I
recently
went
around
to
all
of
the
language
repositories
and
submitted
an
issue
for
like
this
new
event,
API,
and
so
that
was
kind
of
a
big
feature
that
you
know
languages.
Each
language
State
needs
to
be
aware
of
and
have
on
their
roadmap
somewhere,
but
for
stuff
like
that,
I
think
for
the
like
the
issue
that
you
have
here:
I'm
not
aware
of
a
great
communication
channel
for
that
other
than
just
that.
A
A
lot
of
us
are
attend.
A
lot
of
these
Stig
meetings
like
I,
see
that
I
see
that
Riley,
for
instance,
triage
this
this
ticket
here
and
he's
he's
very
involved
with
like.
B
A
B
A
Yeah
and
you
know,
if
you're,
if
you're
you're,
it
also
wouldn't
hurt
to
just
open
one
in
the.net
repo,
now
I
mean
I,
don't
know
what
other
folks
think,
but
I
I
feel
like
it
should
probably
be
an
ins
across
the
board
right.
That's
what
the
spec
is
saying,
at
least
for
traces.
A
That
makes
sense
like
back
ends,
typically
treat
the
status
code.
Often
in
like
a
query.
Kind
of
syntax,
saying,
like
hey
I,
want
to
select
all
requests
with
the
status
code
greater
than
400,
and
in
order
to
do
that,
you
know
it
can't
be
a
string
or
maybe
it
can.
It
depends
on
the
back
end,
but
like
an
INT
is
kind
of
important,
sometimes
for
the
in.
In
those
circumstances,.
A
So
with
that
said,
like
I
I,
think
I
would
be
okay,
making
the
change
in.net
just
because
it
feels
like
it's
probably
very
likely
that
that's
what
was
originally
intended
anyways.
A
Some
of
this
predates
probably
to
the
fact
that
metric
attributes
previously
were
only
strings,
and
that
has
since
that
changed
a
long
time
ago.
So.
A
E
Okay,
I
think
they're
close
to
five
and
we
don't
have
any
more
topics:
added,
no
last-minute
topics,
so
we
can
yeah.
We
can
I
think
we're
like
yeah.
We
can
leave
our
lead
in
a
few
minutes,
early
cool
thanks,
y'all.
Thank
you.