►
From YouTube: 2023-03-23 meeting
Description
Instrumentation: Messaging
A
A
Yes,
Mike
working
space
has
those.
A
Yeah,
it's
pizza
right
here,
usually
I
mean
during
summer.
Obviously
it's
warm,
but
that's
super.
C
B
E
E
D
C
D
C
C
C
Yep
Yeah,
so
basically
this
this
Sunday
we'll
have
the
times
which
this
is
this
one
or
two
week
difference
between.
A
Yes,
we
two
best
week
of
the
year,
because
because
every
meeting
said
on
the
U.S
time
zone
is
one
hour
earlier.
C
D
Oh,
that's
a
yeah!
So
then,
what
like
two
weeks
ago
was
probably
the
worst
ever
because
we've
moved.
C
B
D
Zones
I
didn't
move
to
Arizona
I'm
sick
of
this
time.
It's
on
swish,
okay,
cool
I
think
we're
three
minutes
in
Anthony's,
not
here,
but
we
could
probably
jump
in
and
catch
up,
I
think
we've
probably
got
form,
there's
Anthony,
okay,
cool,
so
welcome
everyone
starting
off.
If
you
haven't
already,
please
add
yourself
to
the
attendees
list
and
if
you
have
a
topic
to
discuss,
add
it
to
the
agenda
and
just
to
start
off.
D
The
late
covers
both
Aaron
and
Anthony
plan
to
miss
next
week's
meeting
I
plan
to
be
here
so
we're
still
gonna
hold
it.
It's
just
yeah
plan.
Accordingly,
I
guess,
cool,
and
so
with
that
Aaron
do
you
have
the
first
item
behind
it
over
to
you.
B
Sure
so,
in
the
maintainers
meeting
there
is
a
proposal
to
try
and
consolidate
as
much
of
the
technical
support
for
open
Telemetry
into
one
place
and
from
the
GC
and
the
TC.
It
seems
like
that
place
might
be
stack
overflow,
so
they
put
out
an
ask
for
maintainers
us
to
regularly
try
and
review
essentially
stack
overflow
tags
with
open
Telemetry
that
might
change
in
the
coming
future.
B
Ask
if
we
want
to
just
have
some
dedicated
time
at
either
the
beginning
or
the
end
of
the
meeting
to
kind
of
triage.
These
and
yeah
see
what
see
where
things
go
from
there.
B
Oh
a
note
that
link
that
I
put
there
is
tags
with
both
open
Telemetry
and
go
specifically,
but
it
might
just
be
the
open
Telemetry
one.
We
want
to
monitor.
D
Yeah
so
I
was
taking
a
look
at
this
on
Monday
I.
Think
it's
not
a
bad
idea.
That'd
be
cool
if
we
could
get
an
open
symmetry
go
tag
specifically,
but
also
logging
into
my
slack
stack.
Overflow
account
I
do
not
have
enough
Karma
to
make
a
tag.
Yet
a
close
looks
like
also
I
haven't
logged
in
there
in
like
seven
years.
It's
like
so.
D
It's
it's
been
a
it's
been
a
long
time,
but
yeah
I
think
that
you're
viewing.
This
is
a
good
idea.
D
One
of
the
other
things
I
wanted
to
add
to
what
Aaron
said,
though,
is
that
the
maintainers
meeting
also
talked
about
trying
to
copy
any
issues
that
are
answered
in
Slack
to
stack
overflow
I
just
want
to
mention
that,
because
I
know
with
Anthony
and
Damien
are
on
here,
and
they
seem
to
do
a
lot
of
responses
in
slack
I'm
not
trying
to
Discount
other
people,
I,
just
I
just
noticed
that
so
like
if
you
all
want
to
also
take
up
the
challenge
of
you
know,
if
you
find
an
issue
in
slack,
is
answered
and
just
copying
the
question
and
then
answering
your
own
question
into
stack.
D
Overflow
is
also
the
ask
from
the
maintenance
meeting
just
because
then
it's
indexable
across
Google
and
like
SEO,
picks
it
up,
so
that
was
kind
of
like
the
main
point
here.
I'm.
Definitely,
okay
with
you
know,
answering
questions
there.
Hey
I,
don't
know
how
we
want
to
work
into
our
workflow
here,
because
I,
just
like
yeah,
like
I,
mean
having
a
group
answer.
D
Questions,
maybe
not
is
necessarily
the
most
easy
approach
if
we
only
have
a
user
response,
but
I
do
think
that,
like
keeping
an
eye
on
this
is
probably
a
good
idea.
I
don't
know
how
to
like,
instead
of
recurring
on
my
reminder,
though,
actually
that
might
just
be
the
answer.
D
E
Always
yeah
set
a
reminder:
I
think
it
would
be
valuable
for
us
to
take
time
at
the
end
of
each
meeting
to
go
through
these
tags
and
see
if
there's
anything
there.
That's
of
interest
to
us
like.
Is
there
anything
there?
That
looks
like
an
issue
that
we
need
to
pull
into
our
repellent
and
fix,
or
or
things
we
can
clearly
respond
to
and
solve.
E
B
E
C
D
B
D
Yeah
I
mean
it's
I
mean.
If
that's
the
case.
There's
then
there's
none
there's.
This
is
probably
the
closest
irrelevance,
but
yeah
I
mean
yeah.
That
sounds
fair.
D
B
Yeah,
that's
why,
like
time,
box
and
and
limit
like
to
new
ones,
so
that
we're
we're
kind
of
saying
updated
if
anybody
wants
to
take
on
the
task
of
going
through
that,
that
is
a
perfectly
valid
extracurricular
activity
honestly
can
earn
you
some
SEC
overflow,
Karma.
D
D
I'm
happy
to
take
a
look
at
this.
I
just
need
to
have
a
reminder,
because
I
will
lapse
into
like
this.
If
I
don't
have
a
reminder
so
I'm
definitely
down,
it,
doesn't
seem
like
there's
too
much
activity
yet
as
well.
So
I
don't
know
we
want
to
go
through
some
of
these
today
or
did
we
want
to
just
slate
this
for
two
weeks
from
now
after
I
see
Aaron
Shaker's.
B
Head
I
I
did
not
ex
I
did
not
expect
us
to
start
digging
into
the
backlog
of
this
at
all,
like
ever
just
monitor
for
new
ones
to
come
in.
C
D
Yeah,
when
we,
when
we
plan
on
checking
in
on
this
at
least
maybe
not
next
week,
because
both
Aaron
and
Anthony
are
gone,
but
two
weeks
from
now
and
just
kind
of
seeing
like
you
know,
because
also
I
think
it's
you
know
we
could
just
see
if
the
community
that
we're
here
talking
about
is
doing
this
on
their
own
and
if
not,
maybe
we
can
prioritize
it
as
well.
B
D
C
D
C
So
basically,
the
initial
idea
was
to
just
use
like
a
gocp,
which
is
the
name
just
to
copy
the
source
code
with
changing
the
package
name.
But
then
both
Anatomy,
Anthony
and
Tyler
said
that
maybe
it
will
be
more
flexible
and
more
powerful
to
use,
go
templates
and
even
Tyler
to
go
to
I
think
once
one
good
use
case
when
it
might
be
needed.
So
basically,
it's
just
using
a
text
template
to
the
from
a
CLI
perspective,
so
you're,
given
as
an
input,
a
template
an
as
a
file,
just
a
hyperlink,
not
hyperlink.
C
D
D
You
know,
render
the
template
to
be
different,
so
it's
also
passed
as
a
command
line
argument
that
says
Json
data
and
it's
dynamic
in
the
sense
that
it
dynamically
puts
us
into
some
sort
of
like
generic
interface.
So
you
know
passing
you
know.
The
same
template
can
also
be
you
know,
pass
through
multiple
packages
and
the
only
thing
you
change
is
the
command
line
or
the
go
generate
comment
so
I
think
it's
kind
of
a
cool
idea.
E
D
Cool
yeah
I
think
it's
a
great
starting
point
to
build
the
console.
So
if.
D
Yeah,
okay,
cool
next
up
on
the
agenda,
I
wanted
to
touch
base
on
the
metrics
API
release.
Yesterday,
Aaron
Anthony
and
Ted
attend
from
the
GC
and
I
met
to
talk
about
versioning
and
evolution
strategies
and
go,
and
so
this
is
right
in
line
at
the
same
time
that
we're
also
trying
to
release
the
metrics
API.
We,
if
you
didn't
see
on
slack
today,
we
have
an
rc2
come
out
for
the
metrics
API.
D
This
is
including
the
changes
recently
to
the
options
and
I
think
there's
only
like
a
small
removal
of
the
know-up.
We
reverted
the
addition
of
a
complete,
no
op
implementation
and
just
removed
one
of
the
methods
there
or
the
functions
there.
I
think
that's
the
main
gist
of
what
actually
went
out
with
the
metrics
API,
so
it
definitely
needs
some
more
eyes
on
it
as
well.
If
you
have
time
to
go,
take
a
look
at
the
rc2
I
think
it's
worthwhile.
D
The
thing
that
is
still
up
in
the
air
is
there's
this
open
question
of
how
we
want
to
evolve
our
apis.
So,
given
our
current
versioning
policy
and
guidelines,
there
was
this
PR
opened
to
talk
about
adding
private
methods
to
our
interfaces,
which
is
something
we've
discussed
before
I
would
recommend
going
here
and
reading
it.
There's
a
lot
of
great
ideas
around
adding
them
and
I
think
there's
some
good
information
on
it.
There's
a
few
different
approaches
to
doing
this.
D
D
The
key
thing
here
is
talking
with
Ted
about
this,
because
Ted
comes
from
the
specification
world
and
was
one
of
the
authors
of
the
versioning
policy
from
hotel's
specification
standpoint.
It's
going
to
require
some
changes
from
the
specification
and
guarantees
from
the
specification
to
enable
go
to
do
this
so
that,
like
it
evolves
in
a
way
that
goes,
versioning
can
also
evolve
at
a
backwards
compatible
way.
The
key
thing
here
is
that
the
SDK
has
to
be
compatible
with
all
versions
of
the
API,
and
so
that's
I
think
the
open
question.
D
So
this
issue
is
the
track.
Can
we
do
that?
Can
we
evolve
the
API
with
a
V2
and
still
support
it
with
the
same
SDK
and
there's
I?
Think
some
open
questions
like
around
the
globals
and
how
particular
like
instrumentation
Library
accepts
particular
providers
so
like
the
Tracer
provider
or
the
meter
provider,
I
think
there's
going
to
be
some
issues
here.
B
D
B
Methods
actually
so
go
ahead,
and
look
at
that
example
code.
If
you
don't
mind,
I
think
sure,
I
I
can
hopefully
explain
it
a
little
bit.
So
here
is
our
simplified
model
from
Tracer
to
spans
right
now
span
V1
is
is
actually
the
span
that
we
have
already
span.
V2
would
be
a
different
type
in
the
V2
package,
but
also
potentially
called
span,
but
they're
different
types.
They
are.
There
are
different
interfaces
completely.
B
D
B
So
if
you
actually
were
to
try
and
run
this,
you
actually
get
an
error,
saying
tracer
what
you
might
call
it:
the
Tracer,
the
actual
implementation
can't
be
a
V1
and
a
V2.
At
the
same
time,.
D
B
That
would
mean
we
either
need
to
start
putting
like
a
V2.
So
like
start
V2
and
what
is
it
Tracer
I
think
on
the
Tracer
provider,
Tracer
V2,
if
we
want
them
to
be
those
same
ones,
I
have
an
alternate
solution
so
that
that
is
one
solution
and
I
will
tell
you
right
now
that
we'll
somewhat
make
the
API
the
the
Tracer
V2
API
ugly.
B
B
So
it
takes
the
it
would
comply
with
the
V1
API
and
the
idea
being
when
you
register
the
V2
Tracer
provider,
at
the
same
time
that
that
registration
will
take
and
generate
the
V1
reference
and
register
that
so
that
all
of
the
different
levels
are
are
monitored
and
if
a
library
uses
the
V1
API
it's
using
the
wrapper
around
the
V2,
making
it
Forward
making
it
backwards,
compatible
right
like
making
it
use
the
same
thing.
B
It
goes
through
all
the
same
recognitions,
except
instead
of
a
what
you
want
to
call
it.
Instead
of
giving
out
a
I,
don't
know
something
on
the
Trace
State.
Instead
of
giving
out
the
trace
state
from
the
V2
package,
it
gets
a
V1
Trace
State
package,
which
means
there
may
be
some
casting
or
some
some
copying
that
might
have
to
happen.
In
those
cases.
B
D
Okay,
I'm,
not
I'm,
not
100
following
this
I
think
I
think
I
get
it,
but
I
think
I'd
like
to
see
code.
E
B
D
Okay,
I
definitely
so
I.
This.
This
approach
definitely
needs
to
be
included
in
this
in
the
stock
yeah,
because
I
like
at
the
end
of
the
day
I
want
to
show,
like
you
know,
when
people
ask
like
what
about
the
V2
approach,
we
just
do
another.
You
know
major
version
bump.
It's
like
I
I
want
this
doc
to
have
all
of
the
issues
and
all
of
the
approaches
that
we
possibly
could
take,
and
so.
B
D
Well,
I
mean
I
think
to
Anthony's
point
like
I
think
that
adding
another
method
to
the
API
to
get
the
old
span
is
like
it's.
It's
a
it's
a
really
poor
experience
from
the
instrument
or
instrument
authors
side
right,
because,
if
you
think
about
it
like,
if
you
update
the
Visa,
you
know
if
you
wanted
to
V2
instrumentation
authors
just
go
and
they
go
like
okay,
here's
the
package
upgrade
like
I'm
gonna
change,
the
import
path,
but
I
can
I
can
guarantee
that
my
existing
operations
work
right.
So.
B
Here's
here's
the
thing:
the
V1
API,
the
the
V1
method.
Isn't
something
I
would
expect
anybody
honestly
to
call,
except
for
us
in
the
SDK
and
the
the
API
you
you
either
enter
the
API
by
getting
a
trace
provider
either
from
globally
or
passed
in,
and
that's
either
a
V1
or
a
V2,
and
all
of
your
methods
on
V2
are
all
of
your
methods
on
V1
exist
on
V2.
They
don't
have
the
same
signature
because
they
are
now.
You
know
a
V2
span
instead
of
a
V1
span,
but.
D
D
B
E
I'm
not
sure
that's
right,
though,
because
the
application
author
is
expressed
an
intent
for
this
to
be
used
and
getting
a
no-op
out
of
that
would
be
surprising
to
them.
They
think.
Potentially,
we
could
have
the
V2
Global
say
if
I
have
nothing,
try
to
get
a
V1
Global,
and
if
that
gives
me
a
no-up,
give
a
no-up
back,
but
then
what
happens
with
V3?
Maybe
right.
D
But
that's
the
thing
is
like
also:
you
have
the
V2,
no
op
saying
that
right,
but
there's
no
guarantee
that
the
operator
is
registering
a
V2,
so
I
guess.
The
other
thing
is
like
there's
only
one
Global
package
right
like
if
you
want
to
split
the
global
package
to
the
V1
Global
and
a
V2
Global
that
that
makes
sense
too,
but
then
there's
nothing
guaranteeing
that,
like
you
know,
the
instrumentation
author
uses
the
V2
Global
and
then
the
operator
is
like
I,
don't
have
a
V2
Global
to
set
so
I'm
not
going
to
set
anything.
D
B
D
E
D
Yeah
yeah,
okay,
Okay
cool,
so
kind
of
just
follow
up
on
this,
like
I,
don't
know
of
a
good
solution
to
the
global
I.
Do
think
that,
like
I,
wanna,
I
wanna
document
what
we
just
said
like
if
we
want
to
split
the
global
package
up
into
you,
know
packages,
we
still
have
this
issue.
I'm
gonna.
Try
to
like
take
that
as
an
action
item
to
comment
to
this
issue.
D
B
So,
unless,
unless
we
want
to
pause
to
make
sure
that
we
can
do
the
V1
like
add
the
method
to
the
API
right
like
unless
that
is
a
hard
blocker,
my
goal
when
I
next
have
Cycles
is
to
start
building
that
secondary
the
the
latter
version
of
what
I
described,
not
not
the
the
one
that
we
were
talking
about
right
now.
D
Yeah
yeah
I
just
want
to
see
because
I'm
still
kind
of
interested,
because
I
still
don't
understand
how
adding
the
V1
method
is
going
to
fix.
The
start
method.
Signature
is,
is
what
I'm
interested
in.
B
D
E
C
E
B
B
The
people
that
I'm
most
concerned
with
are
the
operators,
the
the
people
who
are
writing
the
application
code
that
will
pull
in
the
SDK
and
some
form
of
the
API,
either
by
directly
using
the
API
or
by
using
libraries
that
use
the
API
and
what
happens
is
if
we
add
a
method
to
the
API
so
say
in
four
in
14
it
doesn't
have
ad
links
in
115.
B
B
You
know
the
Span
in
the
SDK
file
isn't
a
trace
span,
because
it's
it's
not
anymore
and
the
correct
solution
there
is
to
go
update
your
SDK,
but
there's
some
kind
of
jump
that
has
to
be
made
in
the
application
authors
logic
to
go.
Oh,
this
is
a
problem
in
with
incompatibilities
between
this
dependency
and
this
dependency.
C
B
That's
my
main
concern.
It
shouldn't
affect
eight
people
who
solely
use
the
API,
so
instrumentation
authors,
they
don't
use
the
sck
because
they
just
need
to
get
a
meter
provider
or
get
a
tracer
provider.
Use
the
Tracer
go
on
their
happy
way.
A
So
this
may
not
be
spec
compliant,
but
how
about
in
vsdk
or
vapi
or
both
on
in
it?
We
would
look
for
the
presence
of
AD
links
in
the
interface
and
if
it's
over
version
is
not
proper
and
then
we
would
just
like
fatal
with
our
own
error
message.
C
But
iron,
if
you,
but
if
you
anyway,
as
far
as
I,
understand,
probably
not
that
well,
you
wanted
to
add
some.
You
know
abstractions
and
work
on
it
in
this
Decay
level
like
module,
it
will
be
the
same
problem
still
right
unless
you
will
not
make
a
like
V2
package
or
something
so.
B
One
potential
solution
is
the
embedding
a
no
op
another.
Like
there's
been
a
couple
different
proposals:
there's
embeda
no
op
and
have
a
separate
interface.
B
There
are
detractions
on
why
we
don't
want
to
do
those
and
I
understand
and
I
I
I
agree
with
with
at
least
most
of
them,
I
think
some
of
them
we
can
we
we
can
do
better,
but
that's
why
that's
why
the
impetus
of
the
V2
API
is
here
is
that
that
avoids
both
of
that
in
that
the
same
code
will
still
compile,
but
there
is
a
way
for
users
to
I
think
to
choose
to
upgrade
to
the
next
version
to
know
to
know
that
they
need
to
upgrade
to
the
next
version.
A
So
that
maybe
you're
a
no-op
solution.
But
if
we
set
up
the
ad
links
methods
in
the
SDK
now
and
make
it
to
know
up,
I
guess
and
wait
for
a
couple
versions,
then
we
can
add
it
to
the
API
because
it
matches
the
interface
in
vsdk,
because
permitted
is
fair.
But
it's
not
based
on
the
interface
and
then
we
can
just
say
we
only
support
versions,
n
and
n
minus
one,
for
example,
and
you
cannot
be
more
than
two
versions:
Divergent.
D
D
Yeah
I
mean
it's
like
you
can
put
end
versions
and
it's
like
well.
What
about
n
plus
one
right
like
there's
just
an
induction
argument
there,
and
so
like
I,
think
that
yeah
you're
always
gonna
have
like
there's
some
issue
here,
where
there's
an
incompatibility
and
it's
about.
How
do
you
want
to
like
handle
that,
like
it
always
comes
back
down
to
like
what
sort
of
behavior?
Would
you
like
to
propose?
D
I,
think
that
you
know
outside
of
the
V2
API
I
would
I
would
recommend
going
and
looking
at
that
other
issue
for
the
embedding
of
Noah,
which
also
talks
about
private
methods
like
I,
think
everyone's
aware
that
we
want
to
maybe
provide
a
no-off.
If
that's
going
to
be
the
case,
but
like
there
are
two
alternative.
Well,
there's
three
methods
for
embedding
private
interfaces.
D
One
do
nothing,
and
then
you
have
the
current
situation
where
it's
just
going
to
be
a
a
forced
compilation,
error,
but
then
there's
also
like
you
know,
adding
methods
in
different
ways
which
could
you
know
explicitly
require
SDK
authors
to
to
make
a
choice
of
what
they
provide.
So
these
are
the
these
are
I.
Think
three
or
four
different
options.
C
Ipad
also
I've
had
once
thinking
mind
also,
but
to
be
honest,
I
think
it
would
be
very
hard
and
like
very
expensive
to
maintain
and
write
so
doing
something
in
the
API
similar
to
log
are
like
one
one
API
for
providing
the
SDK,
but
when
you
receive
you
get
another
API
and
when
you
register
the
provider,
basically
there
is
a
magic
in
the
API
which
converts
and
each
checks
using.
You
know,
for
example,
how
was
it
called
this
type
checking
right,
for
example,
even
if
a
function
is
implemented
then
use
it.
C
C
D
Card
so
look
look
at
the
logger
implementation
you're
talking
about
the
underlying
interface
right.
You
have
to
see
if
your
vlogger
interface
implements
the
underlying
and
if
it
does
call
underlying,
and
then
you
get
the
underlying
implementation.
It's
the
same
thing
here.
If
you
have
API
return
everything,
so
it
has
an
ad
links.
Method
in
the
API
you're
gonna
have
a
panic
if
it
doesn't
implement
it.
Yeah.
C
D
D
D
D
It's
not
inappropriate,
I
think
API
in
the
long
fall
for
the
instrumentation
out
there
and
kind
of
like
what
Aaron
said
like
what
are
you
writing
API
for
is
it
for
the
vendor
so
that
they
can
be
lacks
and
not
keep
up
with
updates,
or
are
you
writing
it?
For
the
instrumentation
author
to
build
this
rotation
from
I?
Think
that's
the
the
key
thing
there
is.
D
A
I
mean
do
we
like?
Would
the
specifications
team
would
be
willing
to
change
the
spec
regarding
having
to
support
all
previous
versions
and
be
able
to
say
that
we
have
a
an
end-of-life
policy?
And
we
say
we
only
support
a
maximum
number
of
previous
versions.
D
No
I
mean
that's
that's
one
of
the
big
things
that
a
temple
is
just
talking
about
with
us.
Yeah.
E
D
You
know
you
can
look
in
the
versioning
deck
it
talks
about
like
this
awesome
tracing
signal
as
like
a
replacement
but
yeah
that's,
and
it
makes
sense
because,
like
you
really
want
that
instrumentation
to
be
stable
right,
like
you
really
don't
want
it
to
be,
where
you
have
an
instrumentation
Library,
that's
working
for
a
customer
and
they
go
and
upgrade
it
and
then
like
if
the
instrumentation
doesn't
compile
because,
literally
like
things
have
changed
under
the
under
the
hood
for
the
instrumentation
API.
D
But
the
rolling
forward
strategy
is
something
that
specification
is
a
favor
of
you
know
like.
If
you
have
issues
with
you
know
the
API
evolves
forward,
but
the
SDK
you
know
it
needs
to
be
upgraded.
That's
something
that,
like
there's,
also
an
Otep
as
Ted
was
talking
about
on
this.
Like
that's,
that's
real,
realistic,
like
saying
that
you
have
to
be
at
the
latest
current
SDK
to
actually
provide
you
know.
The
implementation
behind
the
latest
API
is
something
that
specification
in
the
openstorm
tree
project
is
on
board
with.
D
So
you
know,
having
SDK
authors
come
along
and
say,
like
that's
not
acceptable
is
like
valid
on
their
on
their
part,
but
it's
also
from
the
hotel
side,
not
something
that
they
think
is
valid.
Foreign.
D
The
metrics
API
signal
stable
we're
really
trying
to
double
check
that
we're
hitting
all
the
the
T's
or
crossing
all
the
season
talking
about
the
eyes
because
like
if
we
can
do
better
this
time,
I
think
we
should-
and
you
know
I
think
that's
why
we
want
to
pause
here
and
just
make
sure
that
we
are
are
trying,
because
I
think
I
think
honestly
I
think
that
there's
a
potentially
better
solution
here,
you
know
I,
don't
think
you
know
if.
D
D
Okay,
that's
a
lot
of
words
on
the
on
the
subjects.
It's
obviously
tricky,
Wicket
with
that
I
think
we've
hit
the
end
of
the
agenda.
If
there's
anything
else,
others
wanted
to
talk
about.
It's
not
listed.
D
C
D
Oh
yeah,
this
isn't
off
to
a
good
start.
Yeah
I
haven't
taken
a
look
at
that.
Get
this
in
like
a
few
days.
C
D
Yeah
I
mean
I'll
have
to
take
another
look:
I
haven't
taken.
A
look.
Anthony
is
also
taking
a
look
at
this
before,
but
yeah
thanks
for
calling
it
at
it.
This
is
on
my
list
of
things
to
get
back
to.
E
Is
this
in
the
same
code?
That
was
no
sorry,
it's
a
different
set.
D
B
I
was
gonna,
say
thanks
for
putting
a
comment
there,
because
I
think
a
few
hours
later
it
would
have
had
the
two
hour
two
check
marks
and
everything
to
to
merge.
So.
D
I
think
with
that,
then
we
can
end
I.
Think
there's
some
takeaways
we've
got
stack,
Overflow,
we're
gonna,
look
at
in
two
weeks
and
then
Roberts
PR
for
the
go
Temple.
Then
Aaron
and
I
have
some
action
items
on
the
existing
V2
issue,
but
other
than
that
I
think
yeah.
There's
a
lot
of
other
work
like
only
so
much
time.
You
could
talk
cool,
well,
I,
think
with
that,
then
we
can
edit
here
thanks
everyone
for
joining.
B
Are
there
any?
Are
there
any
other
uses
of
otel
that
people
want
to
bring
up.
B
D
Totally
yeah
thanks
for
remembering
that,
okay!
Well,
if
not,
then
we'll
see
you
all
in
a
week's
time
and
or
asynchronously.