►
From YouTube: 2021-07-08 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
B
B
Thing
that
would
be
better
is
if
we
actually
get
the
stable
release
out,
but
I
don't
know
this
is
pretty
sweet.
A
B
Yeah
and
there's
some
issues
so
yeah
agreed,
I
guess
the
the
downside
of
once
you
actually
get
stable
and
how
does
like
you
get
even
more
eyes
on
it
and
find
more
issues.
But
now
your
hands
are
tied
as
to
what
you
can
actually
fix
or
how
you
can
fix
it
right.
So
yeah.
B
Yeah
time-wise,
okay,
just
a
few
minutes
afterward
after
one.
Let
me
see
if
I
can
pull
up
participants
we're
at
five.
I
think
we're
wait
a
little
bit
longer
for
people
to
join.
I
wonder
if
this
is
gonna
be
a
slow
meeting
just
because
it
is
a
holiday
week.
I
know
that
splunk
had
for
the
u.s
holiday,
the
first
three
days
off,
which
I
found
out
on
friday,
not
the
most
prepared
for
yeah.
I
kind
of
wonder
if
other
people
are
also
just
taking
the
whole
week
off.
B
Surprise
holiday,
best
holiday,
yeah
right,
see,
josh
is
here.
Who
else
are
we
waiting
on
maybe
aaron,
but
he
maybe
he's
not
out.
I
guess
we're
two
minutes,
so,
let's
just
get
started,
then
I
can
figure
out
how
to
share
my
screen.
In
the
meantime.
Please
add
yourself
to
the
agenda
doc
as
an
attendee.
If
you
have
anything,
you
want
to
talk
about,
please
be
sure
to
add
it
to
the
agenda,
and
we
can
jump
in
here
once
I
figure
out
how
to
use
a
computer.
B
B
Okay,
cool
welcome
everyone,
thanks
for
adding
your
names.
The
first
thing
I
think
we
kind
of
want
to
go
over.
Is
the
project
boards
see
what
sort
of
progress
has
been
made
on
here?
I
think
there's
not
been
much
except
for
the
anthony
here,
maybe
anthony
if
you
want
to
give
us
a
little
bit
of
a
rundown
as
to
what's
going
on
here.
I
saw
pr
as
well
for
this
so
looks
like
it's
in
action
but
I'll.
Let
you
talk
about
it.
A
Yep,
basically,
a
one
line
fix
one
in
the
tests,
one
one
to
fix
it,
but
the
hotel
test
tracer
was
just
constructing
a
new
empty
span
context
for
with
new
root,
rather
than
actually
giving
it
a
valid
context
that
has
ids
and
all
of
that
good
stuff.
So
I
updated
it
to
generate
the
span
context
from
the
background
context
rather
than
from
the
parent
context,
so
that
it
doesn't
take
the
parents
span,
context
and
use
the
trace
id,
and
all
of
that
on
that.
B
Yeah
cool
looks
pretty
straightforward
to
me,
so
that
should
be.
I
think,
resolvement
today
probably
merge
that
tomorrow
give
it
to
24
hours,
but
it's
pretty
small
as
well,
so
maybe
not
cool.
I
think
that's
it.
There
were
a
few
new
issues
that
came
in.
I
don't
think
I
see
bogdan
on
the
call,
but
I
I
definitely
talked
to
reach
out
to
him
asynchronously,
because
I
appreciated
all
the
feedback
he's
given
us
he's
got
a
lot
of
really
good
issues,
he's
opening
up
so
yeah.
B
Some
of
those
are
included
in
here.
I
think
these
three
actually
yeah
they're
all
logged
in,
so
this
one
was
kind
of
an
interesting
one
that
I
think
needs
to
maybe
have
another
some
more
eyes
on.
I
was
just
taking
another
look
at
it
right
before
this
meeting.
The
issue
here
is
that
the
link
itself
is
in
the
api,
and
it
includes
this
field
for
dropped,
attribute
account
which,
as
spock
points
out,
is
the
implementation
detail.
This
isn't
something
that's
included
in
the
api
specification.
B
I
think
if
there's
a
possibility,
you
could
argue
that
that's
fine,
but
I
also
think
that
it's
something
that
we've
looked
at
in
the
past
removing-
and
I
linked
in
the
related
issue-
that
this
is
something
that
we've
looked
at
before.
But
maybe
we
need
to
take
a
little
harder
look,
because
maybe
this
doesn't
actually
make
sense.
B
There
isn't
a
requirement
that
any
sort
of
sdk
has
to
implement
a
drop
down
attribute
count,
so
this
field
may
just
be
superfluous
for
a
lot
of
it.
So
I
think
that's
valid
I'd
like
to
take
another
look
in
this
rc
period
to
see
if
we
do
want
to
actually
change
it
right
now.
This
link
is
really
important
because,
let's
see
if
I
can
find
it,
though,
being
the
configuration
file,
but
the
idea
is,
is
that
you're
gonna
pass
a
constructed
struct
of
the
link
type
and
we've
looked
at
in
the
past.
B
B
I
think
that
this
is
an
interesting
topic
that
we
went
through
a
lot
of
discussion,
but
at
the
end
of
the
day,
I
think
that
the
issue
was
that
this
link
type
is
shared
and
it
is
used
in
the
spam
config.
That
being
said,
bogdan
also
opened
an
issue
saying
the
spam.
Config
may
not
make
a
lot
of
sense.
B
It
needs
to
be
restructured
itself,
so
I
think
that
there
may
be
a
chance
to
holistically
look
at
like
the
the
whole
like
spam,
config
and
linking
together
and
maybe
make
the
api
less
implementation
leaking
as
well.
It
may
make
a
little
more
sense.
I
haven't
fully
looked
to
this
man.
Config
suggestions
he's
put
out
yet
so
take
that
with
a
grain
of
salt,
I
guess
but
yeah.
I
think
that's
something
we
could
probably
do.
B
Yeah
yeah
and
I
think,
if
that's
fine,
I
think
that
makes
a
lot
of
sense.
I
think
that
we
could
also,
maybe
just
yeah-
I
think
it's
worth
investigating,
there's
also
this
one
that
he
added.
I
think
it
has
something
to
do
with
the
spam
config,
but
it's
more
of
a
memory
optimization
I
haven't
looked
I
I
was
a
little
confused
by
this,
because
I
I
haven't
looked
to
see
how
we're
actually
allocating
to
the
heap
on
this,
but
I
think
this
is
important
for
performance.
B
I
don't
want
to
have
too
many
heap
allocations
if
we
can
avoid
it,
but
I
think
it's
worthwhile
so
yeah.
I
think
there's
some
config
work
that
we
could
probably
suss
out
here.
That
might
be
beneficial.
A
Yeah,
so
I
think
the
issue
here
is
that
you
know
anywhere
we're
constructing
the
the
new
configs.
We
have
that
new
config
function,
which
allocates
the
config
and
then
returns
it
out.
So
these
cable
analysis
is
going
to
say
yep.
This
needs
to
go
on
the
heap.
It
doesn't
stay
within
this
function,
so
you
can't
just
put
it
on
the
stack,
whereas
it's
only
really
used
in
the
in
the
column
function.
A
A
A
B
Yeah,
I
think
that's
fair,
as
far
as
I
can
tell
it
would
just
be
a
heap
allocation
that
we're
saving
here.
So
then
it's
it's
kind
of
hard
to
measure,
because
then
it's
a
use
case
right.
If
you
have
users
that
are
calling
this
10
000
times
a
second,
that's
a
huge
amount
of
savings
versus
calling
this
once
on
startup.
You
know.
D
Yeah,
but
I
mean
like
we
create
and
remove
spans
a
lot,
that's
kind
of
what
the
essence
of
the
library
is,
but
we
don't
really
create
and
remove
most
other
a
lot
of
our
other
configs
like
we
don't
create
an
a
lot
of
exporters
right,
otlp
experts
we're
not
usually
tearing
up
creating
thousands
of
those
and
tearing
them
down.
So
if
we
have
a
heap
allocation
once
there,
it's
not
necessarily
as
bad.
D
E
Can
I
add
that
I
I've
seen
like
phantoms
of
this
nature
in
the
past,
where
you,
you
see
the
allocation
in
code,
but
it
goes
away
by
the
time
you
compile
it,
because
nobody,
you
have
global,
there's
a
global
state
analysis.
That's
done
if
nobody
ever
takes
a
pointer
and
escapes
it
like
that,
allocation
won't
happen,
and
I
I
wonder
if
that's
what
what's
going
on
here.
E
If
you
study
the
history
of
the
attribute
package,
you'll
see
like
a
lot
of
new
with
like
a
temporary
for
sorting
and
it's
true
that
you
do
see
those
allocations
when
you're
calling
the
sort
function.
But
it's
because
of
recursion
in
the
sort.
I
guess
I'm
not
sure
why
the
compiler
can't
figure
it
out
in
that
case,
but
you
do
see
the
hit
and
there
are
benchmarks
that
measure
it.
So
I'd
like
to
see
the
benchmark
just
to
agree
with
what
we're
talking
about.
B
B
Yeah,
I
agree
again
back
to
the
spankings.
I
think
there's
a
refactor
there
that
may
just
be
trying
to
hit
all
these
different
points.
B
Okay,
we'll
put
the
some
comments
here
for
when
we
do
take
this
on.
We
need
to,
I
think,
there's
some
well
motivated
work
that
we
need
to
do
here
cool.
I
don't
want
to
spend
too
much
time
because
we
could
all
solve
this
and
pair
program
it,
but
I
feel,
like
everyone's
time,
is
better
used
so
moving
on,
so
just
for.
A
For
a
little
bit
of
context,
if
people
hadn't
seen,
I
think
a
lot
of
these
issues
bought
and
erasing
are
coming
from
his
pr
that
just
got
put
up
the
other
day
to
change
the
collector
from
using
open
senses
to
open
telemetry
for
traces.
A
B
Yeah,
which
also
thanks
for
bringing
that
up
anthony
this
is
super
exciting.
I
forgot
to
mention
that
I'm
I'm
like
really.
He
asked
me
and
and
anthony
as
well
to
look
at
some
of
these
benchmarks
here
and
I've
got
to
be
honest.
I
got
sidetracked
just
reading
through
the
pr.
I
think
this
is
really
cool
that
we're
actually
going
to
have
some
internal
dependency
here,
but
I
think
this
is
true
across
the
board.
We
talk
about
use
cases.
B
I
think
it's
becoming
more
common,
that
our
the
sdk
is
actually
being
required
or
dependent
on,
but
I
I
think,
yeah
for
contacts.
This
is
correct
and
for
context
on
the
context.
The
collector
is
a
hyper-optimized
pipeline.
So,
yes,
I
imagine
their
priority
of
optimization
is,
is
probably
a
little
more
stringent
than
we
have
been
historically,
but
not
to
say
we
shouldn't
be.
B
Cool
anything
else
we
want
to
add
before
we
jump
down
to
the
last
one.
B
Cool,
I
think
if
this
is
the
last
one
that
I
saw,
I
realize
it
might
not
actually
need
to
be
done
in
the
rc
or
the
next
rc
that
we
try
to
get
out
or
stable
release
just
from
the
fact
that
it
could
be
added
as
an
option,
but
it
could
also
be
that
we
change
the
calling
structure.
So
I
wanted
to
make
sure
that
we
had
a
maybe
a
plan
before
we
went
forward
on
this
before
we
pulled
it
out.
So
it
looks
pretty
straightforward.
B
I
think
it's
a
pretty
good
suggestion.
The
problem
statement,
meaning
that
like
if
you
wanted
to
create
a
link
span
from
the
current
context
you
had
to
do
essentially
what's
listed
here.
You
have
to
start
the
span,
create
it
with
the
link
with
this
main
context
and
then
put
it
back
into
the
context
itself.
If
I'm
not
mistaken
and
there
was
a
propose
to
say
like
well,
just
have
the
parent
be
usable
link
or
maybe
something
like
this.
I
think
there's
really
great
options
and
they're
good
optimizations,
so
yeah.
A
B
Yeah,
would
you
think
that
the
with
parent
has
linked
just
replace
the
with
new
route
option.
A
B
Yeah,
I'm
just
kind
of
wondering
about
this.
This
value
here
you
know
because,
like
it
seems
like
this,
is
implied
that
you're
going
to
create
a
new
route,
and
so
then
you
know
this
would
be
like
included
as
a
link
or
not,
but.
A
I
like
including
boolean
values
in
those
options
so
that
you
can
have
one
single
invocation
and
use
a
variable
there
if
you've
got
something
else,
that's
controlling
whether
you
want
to
do
that
or
not,
as
opposed
to
having
two
separate
indications,
one
with
the
option,
one
without.
D
My
question:
what
else
does
it
do
if
you
have
with
new
route
like
what
like,
it
obviously
should
give
us
a
new
route,
but
does
it
like
inherit
the
attributes
or
anything
else
like
that.
A
No,
the
only
thing
it
should
do
is
avoid
using
the
parent
span
context
to
generate
the
trace
id,
so
it
should
just
yeah
there
it'll
so
it'll
take
the
puts
an
empty
span
context
into
the
parent's
main
context,
which
then
causes
it
to
say
yep.
I
need
to
generate
both
a
trace
id
and
a
span
id,
and
you
know
all
of
the
rest
of
the
things
that
are
in
the
context
are
available
as
well.
B
Yeah,
this
is
the
second
part
here.
I
think
when
I
first
reviewed
this
yeah
yeah,
just
like
what
anthony
just
said
so
yeah
so
yeah,
it's
all
about
the
id
generation,
and
then
I
think
I
thought
I
thought
that
we
used
to
by
default
link
this,
but
we
took
that
away.
So
I
think
that's
what
bogman's
asking
for
right
now
is
that
we
add
it
back
in
if
I'm
not
mistaken,.
B
Yeah,
okay,
yeah,
I
think
aaron.
If
you
had
some
more
questions
on
this
one,
I
think
we
could
probably
address
those
asynchronously.
You
can't
see
your
face,
but
let
me
click
a
button
or
two
see
if
I
can
find
you
yeah,
so
I
think
that
we
could
probably
fly
from
there.
C
C
Sorry
for
interrupting
there
was
one
like
issue
that
I
created
that
might
be
related.
Basically
from
splunk.
We
got
some
feedback
from
customers
that
basically
the
hotel
is
good,
but
it
lacks
documentation
a
lot
like
there's,
basically
the
guys
that
basically
quite
advanced
need
to
look
a
lot
of
the
at
the
code
base
to
figure
out
stuff.
Why
some
of
the
stuff
could
be
basically
probably
just
shown
on
the
on
the
dock.
C
So,
for
example,
there
are
some
environmental
variables
that
you
can
use
to
have
some
stuff
out
of
the
box
and
you
need
to
go
very
deep
into
the
code
or
into
the
some
detail,
go
dogs.
So,
for
example,
you
have
this
jaeger,
jaeger,
jager
and
them
survivors
and
stuff
like
that.
So
there
was
one
of
the
one
of
the
stuff
that
was
like
set
also
the
auto
resource
attributes.
I
don't
know
if
there
was.
There
was
a
good
example
on
this
one,
so
yeah.
C
So
basically
it
was
a
feedback,
and
maybe
I
will
probably
have
some
time
next
week.
I
could
work
on
the
dogs.
I
know
that
probably
usually
people
do
not
have
time
for
it.
I
would
just
like
to
have
some.
I
don't
know
guidance
like
preferred
preferred
structure,
because
I
see
a
lot
of
ways,
but
it
doesn't
mean
that
it
will
be.
You
know
good.
B
Yeah,
I
think,
just
to
start
off.
We
always,
I
think,
are
open
to
having
documentation
updates.
That's
always
I
mean
substantive
documentation
updates,
I
think,
are
always
welcome.
So
I
this
sounds
reasonable.
I
mean,
I,
I
think,
having
things
buried
in
code
is
never
a
really
good
way
to
interact
with
a
project.
You
have
to
go
find
them.
I
know
david
asphal's
on
the
call,
so
I
can
cough
about
kubernetes
having
that
all
over
the
place,
but
yeah,
I
that's
a
joke
by
the
way,
but
yeah.
B
I
I
think
that's
something
we
could
definitely
do.
I
don't
know
the
best
way
to
to
show
that.
I
think
that
that
probably
have
to
be
something
that
somebody
picked
up.
This
ticket
would
maybe
put
a
proposal
into
this
ticket
to
see
what
they're
going
to
do
is
my
suggestion.
That's
what
I
would
do.
I'd
have
to
look
first
and
really
find
a
list
and
then
understand
like
what's
the
best
approach
there.
Does
that
make
sense.
A
Yeah
I
mean
yeah
go
ahead,
I'm
sorry!
I
I
think
that
there
are
probably
several
ways
we
could
do.
This
we've
got
godoc
we've
got
readme,
we've
got
a
website
right,
and
all
of
these
are
good
options,
but
probably
the
best
thing
to
do
would
be
to
document
them
in
one
place
and
then
in
all
of
the
others
point
at
that
one
place
in
some
conspicuous
manner
so
that,
whatever
way
the
user
comes
in,
they
hopefully
eventually
find
their
way
to
it.
B
Yeah
another
thing,
robert:
if
you're
gonna
pick
this
up,
you
may
be
in
the
best
position
to
maybe
try
to
talk
this
through.
I
don't
know.
I
think
there
might
be
an
issue
on
this,
but
I'd
rather
just
maybe
just
say
it.
We
had
somewhat
of
a
meta
issue
that
we
had
identified
many
months
back
about
this
exact
problem
with
like
documentation
and
just
like
what
anthony
just
said
like
where
did
docs
actually
go?
Where
should
you
know,
neat
users
have
a
preference
for
like
putting
those
docs,
you
know.
B
Do
we
prioritize
godox
versus
the
website?
Docs
like
these
sort
of
things,
I
think
we've
had
some
really
strong
opinions
about
in
the
past,
but
since
they
weren't
documented,
as
time
has
progressed
and
people
have
come
and
gone
from
the
project,
those
opinions,
I
think,
have
changed.
So
if
we
document,
I
think,
where
documentation
should
go
and
how
it
should
be
presented
in
these
kind
of
broad
strokes.
Not
like
you
have
to
put
this
here.
You
have
to
put
this
here
kind
of
thing.
B
It
would
be
really
helpful
for
exactly
what
you're
kind
of
feeling
right
now
or
where.
Where
should
this
go
kind
of
question?.
A
B
I
can
tell
you
in
the
contributing.
B
I
agree:
I
made
an
executive
choice
on
that
one,
but
yeah.
Well
I
mean
I
did,
but
I
also
said
like:
maybe
we
should
have
like
a
best
practices
doc,
instead
of
contributing
but
just
putting
the
contributing
and
that
he
can
blame
me
is
the
problem.
I
think
that's
probably
the
best
way
to
go
forward
on
that
one.
But
that
being
said,
I
think
if
you
wanted
to
work
specifically
on
this,
I
think
that's
totally
fine
too,
as
for
including
in
the
rc.
B
I
think
you
can
do
this
whenever,
in
fact,
actually
I
thought
that
after
we
do
the
rc
there's
probably
going
to
be
a
lot
of
prs
for
documentation.
I
think
a
lot
of
people
are
going
to
be
more
interested
in
the
project
and
I
would
love
to
spend
a
little
more
time
on
documentation.
B
Cool,
actually,
I
could
probably
take
this
off
if
you're
gonna
pick
this
up,
I
think
we're
all
set
then
robert,
I
think
you're
up
on
the
first
agenda
item.
If
you
wanted
to
jump
into
this.
C
Yes,
so
I
just
wanted
to
give
a
heads
up
that
we
we
have
been
doing
it
in
the
like
open
till
everything
go,
so
I
just
had
some
time
because
it
was
a
very
straightforward,
easy
tags
and
I
just
look
at
the
go
country
packages
and
try
to
align
all
of
the
ones
that
I
had
time
to
to
make
the
same
refactoring
I
have
not.
I
had
not
done
stuff
to
the
exporters.
C
There
are
four
packages.
Two
of
them
are,
I
think,
related
to
data
dock,
the
last
two
ones
and
the
second
one.
The
first
ones
are
related
to
cortex,
so
the
first
ones
will
need
probably
significant
changes,
and
I
was
asking
someone
who
looked
as
a
main
contributor
for
help
and
for
the
second
one
I
don't
date
a
dog.
I
don't
know
how
urgent
it
is.
So
that's
why
I
I
have
just
not
done
it
yet.
B
Yeah,
this
is
a
good
topic.
I
think
the
cortex
one,
probably
anthony's
gonna,
be
your
point
person
on
this.
By
that
I
mean
he'll
probably
tell
you
who
to
talk
to,
because
I
think,
if
I'm
not
mistaken,
the
person
who
wrote
the
cortex
exporter
is
no
longer
working
or
as
an
intern
at
aws
right.
I.
A
Think
we've
hired
them
full
time,
but
oh
yeah
there,
if
it's
the
same
person,
I'm
thinking
of
but
there
could.
A
Oh,
no,
we
didn't
he's
not
with
us
at
this
point.
I
don't
think
I
I
thought
this
was
conor,
but
okay
in
any
event,
yeah
the
the
cortex
stuff
was
added,
I
think,
largely
because
of
our
interest
in
the
soon
to
be
at
that
time,
launched
amazon
managed
prometheus
service,
which
is
cortex
under
the
hood.
So
we
still
have
an
interest
in
that
and
I
will
find
someone
or
get
it
done
myself.
B
Yeah
and
then
the
datadog
one
has
always
been
kind
of
a
thorn
as
josh
will
point
out.
It's
just
it's
it's
so
used
in
the
community,
but
there's
not
much
support.
I
think
it
was
the
original
issue
why
this
was
included
here.
I
know
dog,
says
d
is
an
open
format.
This
I
don't.
I
haven't
looked
at
this
in
forever,
so
I
couldn't
actually
tell
you.
E
B
Okay,
yeah,
I
I
I
don't
know
best
effort
on
that.
One
is
probably
what
I
would
try
to
do.
I
think
that
this
they
are
specifically
a
metrics
exporter.
I
don't
know
what
we
want
to
do
here.
This
is
a
little.
B
C
B
It,
I
honestly
think
it's
kind
of
abandoned
at
this
point
and
I
would
question
whether
we
should
remove
it
or
find
somebody
to
support
it,
because
I
don't
know
like
the
open
source.
One
is
definitely
something
I
think
that
we
could
try
to
put
a
little
more
effort
into,
but
this
is
a.
This
is
a
little
bit
harder
one,
because
I'd
have
to
look
again,
but
I
think
it
has
specifics
to
do
around
like
with
the
data.
client,
which
is
proprietary
to
datadog.
B
So
I'd
have
to
I'd,
have
to
dig
into
it
a
little
bit
more.
I
may
may
not
be
saying
accurate
things,
but
it's
harder
to
motivate
open,
open
source
community
support
to
work
on
a
proprietary
exercise
or.
D
D
Like
as
a
as
a
path
forward,
as
somebody
takes
it
as
like
a
fork
of
that,
and
we
point
them
at
the
fork
and.
B
I
I'm
on
board
for
that.
That
sounds
reasonable.
I
know
in
the
past
we
have
asked
datadog
specifically
for
an
engineer
to
take
this
and
move
this
internal
to
datadog,
and
there
was
just
no
movement
on
that
so
yeah.
I
think
your
idea
of
having
some
sort
of
fork
sounds
great,
but
the
question
is
is
like
who
maintains
the
fork
is
another
I
think
concern.
So
if
somebody
wants
to
take
ownership
of
the
fork,
I'm
totally
fine
with
that.
I.
B
I
think
that's
fair:
do
we
call
it
like
the
boneyard
or
something
like
that?
As
the
organization
yeah
give
a
bunny
dog.
B
E
That
was
contributed
by
a
user
at
a
company
that
wanted
to
use,
did
a
dog
and
was
eager
to
try
out
hotel.
I
actually
don't
believe
many
people
would
actually
take
that
route
today
and
a
doubt,
data
dog
would
really
want
to
support
that
either
yeah.
There
is
a
bunch
of
stuff
that
datadog
reports
in
its
client
library.
That
is
not
reported,
you
know,
but
it's
all
resource
information
and
host
information
and
stuff
that
you
know,
hopefully
we're
getting
through
other
routes.
B
Right
yeah,
let
me
see,
I
think
eric
mussen
is
a
data
dog
right.
Maybe
I
can
reach
out
to
eric
to
see
like
what
what
kind
of
guidance
he
would
have.
I
think
I'll
do
that
I'll
try
to
take
an
action
item
on
that
I
I'm
leaning
towards
we
just
remove
it.
Instead
of
trying
to
fix
it.
Robert.
C
Okay,
cool:
did
you
any
thing
else
on
this
one
robert?
I
have
spotted
like
two
things
that
may
be
worth
mentioning.
One
is
that
I
was
thinking
that
maybe
too
good
to
have
a
convention
that
for
to
all
that
all
instrumentation
start
with
the
auto
prefix.
B
B
C
B
An
ecosystem
or
a
place,
and
so
I
think
that
there
was
a
kind
of
an
exception
in
this
naming.
The
runtime
instrumentation
is
not
instrument
to
go
package.
It
does
not
fit
the
structure.
So
yeah
kind
of
saying
that
that
was
the
case
was
why.
C
B
C
So
right,
right
now,
the
all
the
all
the
packages
like
these
packages
uses
the
same
dependencies
and
was
even
checking
that
all
of
them
the
exact
same
dependencies,
but
just
about
consistency
and
maybe
future.
I
don't
know
if
it
will
be
lasting
for,
for
you
know,
for
how
long
I
don't
know
if
in
future
will
not
change
so
we're
just
thinking.
B
A
I
tend
to
lean
slightly
towards
making
them
all
their
own
modules.
I
I
think
currently
all
of
them
have
the
same
dependencies,
but
we
may
at
some
point,
get
one
that
doesn't
you
know
that
would
pull
in
something
additional
and.
C
B
B
Yeah,
okay,
I
didn't
realize
that
that
yeah,
that
would
make
more
sense.
Let's,
let's
do
that
yeah!
There's
no
reason
to
not
do
that
then
yeah
robert,
is
that
something
that
you
can
include
in
one
of
the
pr's
you
already
have
open,
or
is
that
just
an
issue
you
want
to
tackle?
I.
C
B
C
B
Cool
all
right
that
sounds
good.
Anything
else
on
this
one,
robert,
no
perfect,
moving
on
anthony
pr
is
to
consider
for
inclusion
in
the
next
rc.
A
Yeah,
so
I
know
we
said
we
want
to
try
to
minimize
new
features
coming
in
via
rc's
this
one
in
particular,
that
has
been
setting
up
for
a
while.
I
think
it's
got
several
approvals.
It
adds
it's
purely
additive
adds
some
new
resource
detectors.
A
I
think
it
does
play
into
the
the
one
outstanding
issue
that
josh
had
open
about
whether
we
removed
the
the
built-in
detector
or
fold
these
into
it
or
whatnot,
but
I
think
I
would
like
to
propose
that
we
include
this
one
in
the
next
release.
Just
go
ahead
and
merge
it.
B
Yeah,
I'm
I'm
okay
with
that.
I
haven't
reviewed
this
in
a
long
time,
but
I
saw
just
a
lot
of
comments
but
yeah.
If
it's
got
the
approvals,
I
think
I'm
okay
with
including
that
it's
been
active
since
prior
to
the
rc.
I
think
that
it's,
it
has
positive
features,
and
we
already
have
essentially
like
half
of
this.
If
you
remember
correctly,
so
I
don't
see
why
we
wouldn't
want
to
do
something
like
this.
B
I
really
wish
steve
harris
was
here,
though
he
was
the
the
voice
of
woe
last
time.
So
unfortunately,.
B
So
maybe,
while
the
cat's
away,
but
no,
I
I
think
that
this
is
as
if
you
just
can't
point
out
like
this
is
useful.
It's
been
there
for
a
while.
It's
been
an
active
development
for
a
while.
I
would
agree
we
could
probably
merge
that.
A
Let's
do
it
and
then
the
other
one
I
know
you've
been
looking
at
recently.
I
I
had
some
misgivings
about
this
one,
for
I
think
the
the
same
reason
you
added
you
could
end
up
with
non-monotonic
time
values,
but
it's
also
only
gonna
do
that
if
the
operator
of
the
application
is
provided
a
clock,
that's
gonna
do
that,
which
you
know
if
we're
gonna
give
people,
let
people
shoot
themselves
in
the
foot
they're
the
ones
choosing
to
do
it.
A
I
think
this
is
making
it
possible,
but
not
super
easy,
and
it's
it's
a
better
way
of
dealing
with
it,
I
think,
than
building
in
some
ntp
pseudo
implementation,
or
something
like
that.
So
I
don't
know
I
I
don't
have
super
strong
feelings.
Either
way.
Can
we.
B
B
I
don't
want
to
say
it,
but
there's
no
way
we're
going
to
include
an
ntp
implementation
but
like
yeah,
the
the
issue
that
I
have
here
is
that,
like,
I
think
there
is
a
way
to
engineer
away
this
non-monotonicity
and
I
want
to
make
sure
that
we
have
the
right
design
and
if
we
decide
that
we're
going
to
introduce
this
ability
to
have
non-mono
monotonic
ends
start
end
things
or
times.
Then
that's
fine,
but
we
need
to
make
a
concerted
decision
there.
I
think
that,
right
now,
it's
not
really.
B
I
think
it's
it's
possible
to
do,
and
it
doesn't
have
to
be,
is
the
concern
that
I
have
the
overhead
of
the
example
that
I
actually
showed
trying
to
like.
You
know
also
return
some
sort
of
like
stopwatch
with
the
start.
Time
may
have
memory
overhead
so
again,
like
I
think,
there's
trade-offs
here.
So
I
might
want
to
be
a
little
bit
cautious
on
that
and
as
aaron
kind
of
just
devil's
advocated
over
here
like.
I
think
this
is
something
we
could
add
after
the
rc.
B
That
would
that
would
be
fine
to
include
afterwards.
E
E
B
Think
I
think
it's
it's
just
drift.
I
don't
know
if
it's
specific,
particularly
the
long
span
thing
I
didn't
get
that
from
it,
but
it's
just
the
clock
drift.
You
know
it's,
it's
an
inevitable
problem
that
different
systems
are
going
to
have
different
understandings
of
what
absolute
time
is,
and
you
know
ntp
is
this
idea
that
you
could
try
to
like
minimize
that,
and
so
the
goal
here
is
to
eventually
in
your
back
ends.
Have
you
know
spans
from
different
parts
of
different
systems
that
are
running
you
know?
B
Maybe
the
same
service
show
relatively
close
by
doing
that,
just
like
synchronizing
time
across
your
fleet
is
kind
of
the
idea
here
and
I'm
like
that's,
not
really
a
concern
of
this
project,
but
I
think
if
we
provide
an
interface
that
allows
you
to
do
that
on
your
own
and
then
maybe
like
tell
us
what
the
time
is.
That's
fine,
like
you
can
do
whatever
you
want
there.
That
sounds
like
a
totally
reasonable
thing.
Okay,
go
ahead.
E
That
sounds
good
yeah.
I
just
don't
think
it's
really
about
monotonic
monotonicity
like
goes
time,
object,
kind
of
solves
that
if
you
do
it
right
well
so,
but
solving
direct,
I
think,
is
independent
clock
drift,
although
preferably
you'd
just
fix
your
system
clock,
but
I
know
that
that
doesn't
always
work.
B
E
B
So
josh,
I
think
that
you
are
in
really
good
company,
because
it
was
actually
your
implementation
of
like
the
clock
interface
that
started
off
this
conversation.
I
was
pointing
towards
that
in
the
metrics
question
and
it's
it
was
actually
one
of
the
prime
reasons
we
started
with
the
current
interface
plus
they.
You
know
we
did
think
about
abstracting
into
a
unified
time
package
or
something
like
that
that
would
be
used
across
all
packages.
I
think
we're.
B
E
Problem
for
us
yeah,
somebody
actually
believe
they
ought
to,
and
probably
I've
thought
about
it,
but
I
don't
want
to
you
know
before
I
shut
up
I'll,
just
say:
light
steps.
Tracer
libraries
do
include
an
ntp
like
thing:
it's
the
worst,
the
worst
and
the
most
like
unreliable
garbagey,
like
idea,
and
I
would
never
support
it
so.
D
I
I
think,
like
being
kind
of
their
devil's
advocate.
The
ask
here
is
to
allow
for
a
different,
a
different
clock
source
than
the
system
clock.
Then
the
built-in
clock
from
go,
and
I
can
see
some
very
specific
applications
like
if
you
have
something
that
is
hooked
up
to
a
gps
clock
or
an
atomic
clock.
You
may
not
be
getting
a
your
system.
D
Clock
may
not
be
updated
against
that,
but
your
you
could
have
a
potential
other
source
of
clock
information
that
is
more
accurate,
that
you
would
want
to
be
using.
That
being
said,
that's
that's
like
a
real
specific
use
case
and
I
don't
know
like
a
hundred
percent
if
I
would
support
something
that
like
if
we
can
do
this
and
there's
very
little
overhead,
no
overhead
in
our
process
and
I'm
fine
with
it
like
that.
D
That's
fine
right,
you
know,
but
supporting
new
use
cases
but
like
it
has
potential
of
you
know
it
a
introduces,
a
foot
gun,
I'm
I'm
very
scared
of
having
foot
guns
because
that's
just
more
support
tickets.
Always
that's
all
it
is.
I
be
like
there's
potential
for
big
overheads
on
this.
So,
like
I
wanna
make
sure
that
we've
sus
any
kind
of
performance
hit
that
we
might
have
with
this.
Since
we're
now
gonna
go
from
calling
directly
time.now
to
you
know,
time.current
or
whatever
it
is.
You
know
through
an
interface.
A
State
the
the
performance
implications
should
be
fairly
limited
right,
there's
some
logic
that
happens
in
the
option
to
set
the
clock
on
the
provider
and
the
rest
is
a
straightforward
change
of
time.now
to
clock.now
or
time.sense
to
clock
that
sense.
So
unless
the
the
user,
who
provides
their
own
custom
clock,
puts
a
30
minute
sleep
in
there
or
something
like
that,
the
performance
impact
should
be
limited,
yeah
right,
but
but
in
the
default
case,
if
the
user
doesn't
do
anything,
there
should
be
little
or
no
performance.
B
Thing
to
include
and
yeah
like
you're
saying,
like
you,
can
do
whatever
stupid
thing.
You
want
in
your
clock
thing
and
it's
obviously
going
to
have
performance
overhead
because
you're
not
you're,
just
not
in
the
you
know
the
happy
path
like
the
critical
like
you're,
just
doing
the
simplest
thing,
but
I
don't
think
that's
something
that
we
need
to
be
concerned
with.
B
I
think
we
need
to
be
concerned
with
this,
which
is
what
what's
being
shown
here
is
like
when
you
add
this
new
clock
interface
versus
when
the
original,
and
I
think
that
you
see
the
same
alex
you
see
the
same.
You
know
operation
speed,
essentially,
there's
you
know
negligible
amount
of
actual
overhead
here,
so
I
think
that's
it
seems
reasonable,
like
this
isn't
actually
adding
too
much
of
an
overhead.
It
is
important
because
this
is
definitely
in
the
hot
path.
B
We're
talking
about
spaying
creation,
times
start
and
ends
here,
so
it's
definitely
something
to
be
critical
of,
but
yeah.
I
think
the
the
main
thing
that
I'm
looking
at,
I
was
just
sorry
halfway.
Reading.
This
comment
as
well
is
just
that,
like
there's
a
host
of
issues
when
you
try
to
decide
to
find
an
interface
like
this,
and
you
try
to
use
the
sense,
mostly
it's
it's,
it
doesn't
seem
like
it's
being
really.
B
I
don't
know
taking
a
heart
but
like
the
the
problem
arises,
if
you
have
an
offset
from
the
original,
like
you
have
an
entity
update
in
the
middle
of
some
sort
of
span,
that's
already
started
you're
you're
going
to
have
a
skew
on
your
end
time.
Your
end
time
is
going
to
include
whatever
skew
you
just
included
into
the
actual
underlying
time,
and
that
doesn't
have
to
be,
especially
if
you
want
to
define
the
interface
where,
with
you
know,
whatever
start
time
you
actually
have.
You
have
also
a
return.
B
D
C
C
B
Yeah
and
that's
exactly
what
you're
saying
josh
is
you
know
how,
then,
how
do
you
wrap
those
two
things
in
some
sort
of
interface
structure?
And
how
do
you
pass
that
through
the
chain
there?
I
think
there
are
multiple
different
ways,
but
what
you
just
described,
I
think,
is
the
right
solution.
The
wrong
solution,
I
think,
is
just
to
assume
that
everything
is
going
to
work
out
just
fine
by
getting
one
time
stamp
and
then
the
time
stamp's
going
to
do
everything
you
need.
B
You
need
that
added
duration,
for
whatever
it
is,
but
back
to
the
kind
of
the
original
question
is
like.
Should
this
be
included
in
the
rc
I
I
would.
I
would
like
to
think
about
this
like
a
little
bit
more
and
and
maybe
put
some
thought
into
it,
but
maybe
next
week
it'll
be
a
little
bit
more
solidified.
So
I
think
that
I
would
not
want
to
include
this
this
week
is
what
I
would
say.
A
B
After
ga
man,
this
project
is
gone
through
a
lot
of
different
terminology
changes.
B
Cool,
I
think
the
next
thing
is
garrett.
We
kind
of
ended
last
time
talking
about
the
oh
aws,
orlando
stuff,
so
maybe
we
can
kind
of
check
in
with
you
again.
F
Yeah,
I
don't
have
much
today,
I
was
just
gonna,
say
so
pretty
much.
F
I
was
hoping
by
this
meeting,
but
that
didn't
happen,
but
by
probably
the
end
of
the
day
today,
I'll
have
like
a
draft
pr
up.
We
don't
want
to
actually
merge
anything
until
we
do
our
full
testing
suite
and
like
pen,
tests
and
stuff
on
our
side,
but
in
theory
I'll
have
it
up,
so
that
anybody
who
once
can
review
it
and
go
over
what
what
all
it
does.
F
I
went
through
the
comments
that
he
put
robert
on
the
dock
last
week.
I
haven't
actually
left
any
replies
on
there,
but
I
I
have
looked
at
them,
but
yeah.
It
was
really
just
an
update
that
hopefully
fingers
crossed
later
today.
Some
some
draft
of
the
pr
will
be
up
so
you'll
kind
of
get
a
better
idea
of
what
all
is
going
on
and
any
feedback.
F
There
would
be
awesome
because
we'll
just
kind
of
be
sitting
on
like
the
code
that
goes
up
there
will
just
be
sitting
on
for
like
a
week
or
two
till
we
hear
back
from
our
stuff.
B
Cool
that
sounds
great,
we'll
all
hopefully
look
forward
to
that
and
give
you
plenty
of
reviews.
That
being
said,
I
also
just
realized,
after
my
surprise,
vacation
that
I'm
out
monday
wednesday
friday,
I'm
sorry
monday,
tuesday,
friday.
That's
how
days
go.
That's
not
hot
days
monday,
tuesday,
wednesday,
is
what
I
meant
to
say.
Sorry.
So
I'm
about
out
half
again
the
week
I'll
learn
how
to
speak.
English.
B
When
I
come
back,
sorry
yeah
as
aaron
said
no
there's
no
way,
I'm
gonna
learn
so
yeah
don't
ever
learn.
It's
not.
B
Just
a
heads
up
on
that
one
at
the
it
looks
like
anthony's
got
a
a
late
to
the
game.
Pr
or
we
want
to
talk
about
here.
A
Yeah,
so
speaking
of
draft
pr's-
and
we
have
a
bit
of
time-
this
might
be
a
good
time
to
bring
this
up.
So
bogdan
has
a
draft
pr
proposing
that
we
change
the
hotel
test
package
to
use
the
sdk
with
the
goal
of
eliminating
duplicate
code
and
perhaps
eliminating
sources
of
defects.
I
want
to
know
what
other
people
think
about
this.
A
I
think
this
comes
from
some
internal
stuff,
that's
depending
on
stuff
that
got
moved
there,
so
maybe
that's
just
a
reshuffling
that
can
happen,
but
I
want
to
to
get
kind
of
a
sense
of
people's
thoughts
about
the
the
utility
of
the
hotel
test
package,
and
should
it
be
an
independent
implementation
designed
for
testing,
or
should
it
be
mostly
just
a
spam
recorder
that
can
be
put
in
as
a
spam
processor
in
the
existing
sdk.
B
Yeah
thanks
for
bringing
this
up,
I
wanted
to
talk
about
this
as
well.
I
definitely
think
boxing
messaged
me
a
synchronous
millionaire.
I
don't
think
he's.
Gonna
come
back
and
update
this
pr,
so
it
was
more
just
proof
of
concept,
so
just
to
give
context
on
that,
but
I
totally
agree
with
what
you
put
here
like
this.
Definitely
shouldn't
get
merged
as
it
is.
B
I
I
do
think
that
there
is
a
possibility
to
remove
duplicate
code
and
avoid
some
sort
of
you
know
different
implementations
of
the
same
thing
in
different
places,
kind
of
problem.
I'm
I'm
a
little
questioning,
I'm
questioning
how
it
is
approached
in
this
pr.
B
I
also
am
a
little
bit
concerned
because
yeah
if
the
hotel
test
package
is
used
outside
of
hotel
test,
like
I
noticed,
the
hardness
is
gone
in
this
pr
and
if
somebody
else
is
running
their
own
sdk
and
they
want
to
run
the
harness
which
may
not
be
the
most
complete
harness,
but
it's
useful
it's
better
than
nothing
that
we
provide.
B
E
E
A
E
A
little
both
I
actually
have
wanted
both
so
so
either
would
make
me
happy
in
some
in
some
setting,
probably
more
interested
in
getting
that.
Telemetry
is
functional
for
my
library
and
second,
that
I
my
main
function
actually
is
you
know
like
it's
often
when
I
crash.
D
Yeah,
honestly,
I
think
both
of
those
use
cases
would
probably
be
solved
by
the
same
thing,
but
I
don't
think
that
the
oh
tell
test
was
kind
of
focused
on
that.
It
seemed
like
it
was
focused
more
on
lines
of
testing.
The
internal
thing
is
working
with
a
mock,
which
is
a
good
set
of
tests
for
like
internal
self-sanity,
but
I
think
that
would
actually
be
something
really
useful
as
well.
A
Well,
I
think
it's
also
used
in
contrib
fairly
extensively
to
test
the
instrumentation
right
so
using
it
as
an
sdk
that
doesn't,
you
know,
isn't
the
actual
live
sdk
that
that
only
exports
to
the
spam
reporter.
So
you
can
go
and
then
look
at
the
spam
reporter
and
say:
did
my
instrumentation
actually
create
the
spans?
I
expected
it
to
create
and
that's
how
bogdan's
been
using
it
in
the
collector
right
he's,
adding
some
instrumentation
using
hotel
tests
to
make
sure
that
the
spans
expected
to
be
created
or
created.
A
So
I
think
that
takes
care
of
that
first
use
case.
The
second
use
case
would
be
having
the
span
recorder
usable.
I
think
it's
like
a
a
span
processor,
but
that
I
think,
is
an
sdk
specific
implementation,
so
probably
would
need
to
live
in
a
separate
package
or
a
module,
or
maybe
something
that
we
add
to
the
sdk
somewhere,
which
the
sdk
could
then
just
delegate
back
to
the
spam
recorder.
I
think.
B
B
We
should
try
to
design
it
to
be
exactly
what
what
you
just
said
like
if
you're
writing,
instrumentation
it
provides
the
useful
box
or
constructs
that
you
can
use
in
your
testing
to
you
know
verify
that
things
are
correctly
being
transmitted
like
it
is
being
used
in
the
contrib,
and
maybe
it's
not
clear
that
those
sort
of
constructs
exist
like
in
josh's
case.
Maybe
you
just
didn't
like
know
where
they
are
so
maybe
some
better
docs
on
how
to
like
write
that
additionally,
it
also
does
create
the
harness.
B
B
They
could
be,
I
think
I
think,
you're
right.
E
B
A
I
think
the
fake
sdk
or
the
real
sdk
with
the
fake
fan
recorder
is
the
thing
that
doesn't
exist.
Currently,
the
other
thing
is
the
test,
harness
which
you
hand
an
sdk
to,
and
it
puts
it
through
a
set
of
paces.
It's
like
an
instrumentation
that
is
is
observing
the
the
sdk
implementation
and
making
sure
that
it's
correct
for
some
values
of.
B
Correct
yeah
and
I
I
they
came
from
two
different
packages.
I
know
like
we
merged
these
a
while
ago,
so
it
could
be.
I
also
don't
know
how
used
the
harness
is.
I
know
we
use
it
a
few
different
places
internally,
but
I
don't
know
how
used
it
is
externally.
B
I
don't
know
if
anybody
I
haven't
heard
of
anybody
actually
write
their
own
sdk.
Yet
I've
done
it
a
little
bit
back
in
the
day,
but
that
was
way
before
this
complicated
stuff
happened.
So.
D
I
I
would
also
argue
that,
potentially,
unless
we
are
going
to
completely
divorce
the
harness
from
this
implementation,
there
is
a
good
chance
that
whoever
writes
the
second
sdk
is
going
to
have
to
write
their
own
harness
anyways.
D
Just
because,
like
our
sdk,
is
very
much
tied
with
our
current
implementation,
and
I
would
expect
our
harness
to
be
tied
with
our
current,
like
our
current
api.
So
I
think
that's
kind
of
like
a
secondary
goal
of
the
test.
Harness.
B
Well,
the
harness
was
intentioned
to
be
sort
of
a
specification
check,
so
in
theory
anybody
who
writes
their
own
sdk
has
to
implement
the
api
because
otherwise
they
can't
really
register
it
essentially
right.
So
all
the
harness
does
is
call
api
methods
and
it
causes
api
methods.
Looking
to
verify
that
the
functionality
that's
in
the
specification
is
there.
The
problem
is
it's
not
comprehensive,
like
it
only
does
partial
specification
verification,
because
it's
hard
like
you,
can
get
a
factory
to
create
things,
but
it's
hard
to
then
verify
them
that
they
were
created
properly.
B
So
maybe
that's
all
something
that
could
change
but
yeah.
It's
it's
just
calling
api
methods
and
saying
like
can
I
do
this
so.
A
Yeah
yeah
it
happens,
it
receives
interfaces
that
describe
the
expectations
for
it,
so
it's
this
would
be
something
that
would
be
used
by
the
sdk
author
to
say
here,
harness
here's,
my
sdk,
here's
what
I
expect
to
come
out.
You
choose
how
to
validate.
That
has
actually
done
the
right
thing
and
then
the
harness
runs
it
through
its
paces,
mostly,
I
think
to
try
to
identify
edge
cases
right.
Have
you
worked
through
this
pattern
of
interactions
that
the
api
needs
to
be
able
to
handle
that
sort
of
thing.
B
We
did
kind
of
talk
about
the
hotel
test
package
not
being
included
in
the
release.
I
think
there
was
some
detangling
of
dependencies
that
needed
to
be
done
if
we
weren't
going
to
include
those
problem,
as
I
think
is
pointed
out
by
the
pr
here
that,
like
you,
know,
removing
this
and
puts
a
dependency
on
the
sdk,
I
think
that
hotel
test
is
going
to
be
a
dependency
on
the
api.
B
Just
because
that's
what
we
use
for
testing,
but
it
might
be
something
we
want
to
pay
a
little
bit
more
attention
to
and
and
do
a
little
bit
more
of
a
deep
dive
in
before
we
release
it.
I
don't
know
if
that's
something
we
want
to
put
the
brakes
on
a
little.
B
Okay,
I'm
going
to
use
the
issues
that
bogdan
opened
to
try
to
motivate
that.
I
think
that's
that's
worthwhile!.
B
Cool
we're
nearing
the
end
of
the
time
we
have
a
minute
and
a
half
left.
Does
anybody
have
any
screaming
awesome
use
cases
that
they've
experienced
in
the
past
week.
B
I'm
seeing
a
lot
I'm
seeing
a
lot
of
blogs,
I'm
seeing
a
lot
of
adoption
of
the
rc,
maybe
it's
just
because
there
was
very
little
beforehand,
but
I'm
pretty
excited
by
a
lot
of
this
stuff.
So
it's
only
going
up
into
the
right.
I
think
the
the
collector
one
is
a
really
cool
use
case,
so
I
think
I'm
glad
we
got
to
show
that
that
they're
switching
over
to
the
implementation
using
this.
So
it's
definitely
a
positive
feedback
that
we're
doing
something
right.
A
And
one
more
note
more
generally
hotel
project
general
is
oops
is
that
the
the
hotel
project
has
been
approved
for
incubation
with
the
cncf
unanimously
by
the
trc.
There
was
one
non-binding
expression
of
descent
that
I
saw
yesterday.
I
don't
think
I've
seen
any
others,
and
that
was
the
the
the
issue
we
raised
was
that
metrics
and
logs
aren't
stable,
which
is
a
fair
point,
something
we're
working
towards,
but
I
think
it's
great
that
the
project
as
a
whole
has
demonstrated
maturity.
A
B
Absolutely
yeah:
congratulations!
Everyone
cool
with
that!
I
think
we
can
end
it
right
on
time.
So
I'll
see
you
all
next
week
I'll
be
back
by
thursday,
because
I
know
how
to
know
what
days
they
are
and
otherwise
I'll
see
you
virtual
I'll,
try
to
check
in
in
early
week,
but
I'm
probably
gonna
be
pretty
busy
so
bye.
Everyone
thanks.