►
From YouTube: 20230125 SIG Arch Prod Readiness
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
Project
meeting
for
January
25th
2023.
as
I
was.
A
Saying
I
didn't
did,
did
we
record
the
last
meeting
I
didn't
check
so.
C
No
because
none
of
us
found
the
admin
key,
the
the.
C
To
record
it,
we
did
take
notes.
I
can
catch
you
up
briefly,
Sergey
who's.
Actually,
here
again,
he
left
us
so
much
he
came
back
was
asking
for
some
recommendations
for
filling
out
prr
on
a
cap
that
was
going
to
have
some
difficult,
SKU
guidelines.
C
So
we
pointed
him
to
a
couple
examples
that
had
worked
out
pretty
well
and
then
said,
be
very,
very
careful
with
signode
make
sure
cignode
pays
very,
very
close
attention
because
skew
there
is
hard
and
reasoning
about
what
breaks
or
not
is
important
and
whether
it
fails
open
or
closed.
The
other
thing
that
came
up
is
Mo
wanted
to
be
a
prr
Shadow.
C
C
Nearly
everyone
responded
and
said
they
want
to
come
back
and
so
I
think,
given
the
number
of
kepts
we
are
currently
tracking
I.
Don't
think
there
is
space
to
to
add
move
this
time
unless
there's
an
unexpected
Avalanche
the
next
three
days.
There's
just
if
you
look
at
it,
there's
only
going
to
be
looks
like
a
total
of
about
the
same
as
before.
There's
50
now,
I
figure
we're
gonna
get
a
bunch
more,
but
it's
probably
not
going
to
be
over
80
and
of
those.
C
Many
of
these
are
repeats,
and
so
there
won't
be
an
opportunity
to
do
fresh
reviews
on
all
of
them
and
I
believe
that
covers
what
happened.
While
you
were
out.
I
guess:
I
want
to
add
to
the
agenda
I
at
the
end
or
after
after
Sergey
I'd
like
to
talk
about
how
we
divvy
up
Shadows
for
their
second
attempts
and
what
our
second
step
second
round
and
figure
out
how
we
can
best
make
the
experience
useful.
A
Okay,
that
sounds
great
and
that's
what
I
wanted
to
talk
about
too
is
so
we
will
defer
that
to
after.
A
D
Thank
you
just
to
follow
up
on
yesterday,
like
last
couple
of
weeks,
discussion
about
sidecar
container
we're
making
a
great
progress
and
White
agreed
to
be
a
PR
reviewer
for
that,
thank
you
still
being
Alpha,
so
it
will
be
easier
stage,
but
we
already
at
least
in
problems
with
further
stages
as
well
and
today,
I
just
stopped
by
to
ask
some,
maybe
like
past
experience,
what's
happening
with
other
caps
with
regards
to
scalability
tests.
D
So
we
recently
discovered
this
nasty
bug
with
HTTP
probes
when
HTTP
problems
become
unusable
because
I
mean
HTTP
props
running
from
couplet
to
many
many
different
ports
like
because
every
container
has
its
own
port
and
every
kind
of
probe
typically
also
has
a
separate
port,
or
something
like
that.
So
we
have
a
lot
of
sockets
pin
open
and
because
of
how
TCP
is
implemented
on
Linux,
they
socket
will
linger
for
a
while,
even
after
we
receive
the
response
from
from
a
endpoint.
D
So
we
can
end
up
using
so
many
sockets
that
will
just
run
out
of
resources
or
node
and
all
hcp
probes
will
start
failing
with
the
like
client,
timeout.
So
client,
being
HTTP
from
Google
at
Canada
get
any
socket
to
start
the
HP
connection,
so
we
will
start
killing
ports
all
the
continuous.
Even
though
containers
are
perfectly
normal
and
perfectly
like
operating
fine.
D
We
don't
exhaust
any
resource
on
containers
level
only
on
node
level
yeah.
So
that's
a
context
and
like
we
just
covered
it
through
some
customer
reports
and
also
from
that,
is
not
open
source.
But
as
this
Cloud
boost
test
also
like
I,
didn't
find
the
moment
it
started
failing
it
just
started.
D
Failing
at
some
point,
so
I
was
wondering
how
much
my
PR
review
is
enforcing
and
like
okay,
next
stage,
step
in
my
logical
chain
is
I
will
be
proposing
a
ga
of
grpc
probes
and
grpc
probes
has
the
same
exact
problem
as
HTTP
Pro
because
they
say
they
use
I
mean
maybe
not
the
same,
but
a
similar
problem
like
clean,
getting
circuit
connections.
D
E
I
think
this
is
like
thing
that
we
didn't
yet
really
formalized
and
or
they
didn't
really
try
getting
deep
into
I
think
we
are
pretty
much
focused
on
like
the
control
plane
side
where
most
of
their
aggressions
and
most
of
the
problems
were
appearing.
E
E
It
might
also
be
difficult
to
do
to
to
to
have
some
like
generic
enough
questions,
to
actually
watch
different
kind
of
kind
of
issues
like
that,
because
it's
it's
fairly
specific
one
to
me.
I.
A
Mean
there
could
be
questions
so
like
like
in
in
the
questions
we
added
for
scalability
I.
Think
we're
taking
you.
Do
you
ask
about
control
plane
stuff,
like
how
many
new
API
resources
are
made?
How
many
new
calls
to
cloud
provider
I
mean
we
could
ask
the
question
of
what
what
limited
resources
does
this
consume
on
the
Note
right?
So
you
know
that
could
be
pids.
It
could
be
sockets,
it
could
be
file
descriptors,
it
could
be,
but
like
are
there
limited
resources
that
this
consumes?
A
Are
there
cases
where
you
might
hit
you
limits
or
other
issues,
constraints
on
the
Node?
Just
ask
that
one
question
so
people
think
about
I,
don't
know.
Would
that
have
caught
it?
Would
the
people
have
thought?
Oh
60,
second
timeout
yeah.
We
could
hit
that
if
there's
a
lot
I,
don't
know
if
they
I
don't
know
if
they
would
have
caught
it,
but.
E
No
yeah
I
I
really
liked
it
because,
like
this
is
like
generic
enough
question
and
like
it
won't
explode
into
into
addition
of
like
another
10
questions
later
and
yeah
it
it's
possible
that
we
didn't
call.
We
wouldn't
catch
that,
but
I
think
it
will
at
least
force
people
to
think
about
it,
which
is
which
is
probably
the
most
important
thing.
C
David
yeah
I
was
going
to
point
out
that
when
we
ask
these
questions,
the
expectation
isn't
isn't
perfection
right,
I.
The
thing
you
mentioned
about
like
report
uses
sticking
around
for
a
while
that
wouldn't
have
occurred
to
me
when
reviewing
it.
So
if
you
would
answer
the
question
and
said
no,
no
expectation
we're
making
more
of
these
calls,
but
no
expectation
we're
going
to
hit
any
limit,
I
wouldn't
have
caught
it,
but
no
issue.
Adding
a
question
to
make
people
think
just
remember
that
stuff
happens.
Yeah.
A
E
D
A
Dates
and
stuff
like
that,
we
can't
instantiate
new
clusters
with
different
sets
of
feature
gates
in
our
test
framework,
and
so
we
asked
for
you
to
test
around
feature
Gates,
but
you
can't
really
do
an
integration
test
like
I.
Think
similarly
other
than
manually,
like
I,
think
it's
too
much
to
ask
I.
F
A
A
E
Yeah
we-
and
we
are-
we
are
those
are
like
pretty
focused
on
like
control
plane
and
when
we
see
something-
or
at
least
when
I
see
something
like
that,
has
a
potential
to
to
affect
scalability
I'm
asking
this
question
and
I'm
asking
at
least
for
some
manual
tests
like
it's.
E
Usually
it's
usually
relatively
easy
to
to
like
modify
the
test
and
do
some
manual
one
of
but
it's
it's
focused
pretty
much
on
like
control,
plane,
so
I
I
think
we
would
need
some
examples
that
we
can
refer
to
for
note
or
for
node
features
so
that,
like
people
don't
have
to
like
reinvent
the
wheel
before
we
will
start
asking
for
that.
A
So
like
like,
let's
just
maybe,
let's
just
use
this
example
and
see
whether
like
like,
if
you
had
to
take
a
node
you'd,
have
to
have
you'll,
have
to
configure
a
bunch
of
probes
that
are
frequent
and
you
have
to
run
a
bazillion
pods
and
have
those
hitting
and
you'd
have
to
somehow
watch
the
consumption
of.
A
Was
it
ports
or
file
descriptors
or
whatever
was
running
out?
Would
our
test
framework
make
that
something
feasible
and
reasonable
to
do?
Or
would
we
be
putting
an
undue
burden
on
a
feature
author,
or
do
we
need
to
add
some
functionality
to
our
test
framework
in
order
to
do
that?
I'm
kind
of
asking
Ben
here
what
you
think.
F
Well,
I
mean,
let
me
put
it
a
different
way
at
one
point:
we
added
Windows
support
and
obviously
nothing
had
Windows
support.
We
didn't
ask
like
Sig
testing
to
to
build
out
e2b
testing
Windows.
It
was
on
the
people,
shipping
Windows,
to
sort
that
out
and
they
can
get
insight
from
the
Sig
but
like
we
didn't,
suddenly
drop
everything
and
build
testing
for
that.
I.
F
Think
if
you
think
something
is,
if
you
think
that
there's
some
risky
aspect
of
a
feature
or
that
a
feature
needs
to
be
shipped
it,
then
it
should
be
tested
and
if
the
tooling
isn't
there,
then
that's
just
part
of
shipping.
The
feature
we've
had
a
lot
of
different
cases
where,
like
we
have
to
figure
out
some
new
way
to
test
something.
F
We've
had
some
interesting
constraints
with
you
know.
If
you
really
want
to
ship
your
feeder,
we're
kind
of
expecting
that
Things
become
conformance
tests
and
it
can
be
very
awkward
to
sometimes
to
test
things,
because
you
have
to
like
make
sure
that
it's
portable
and
it
doesn't
depend
on
things
outside
of
the
kubernetes
API
to
actually
execute
the
tests.
A
Maybe
this
is
just
a
general
case
right
of
of
high
density
like
really
what
this
comes
down
to
is
very
high
density,
pods
and
probes
in
particular,
but
like
like
from
a
scalability
perspective,
how,
on
that
dimension
of
pod
density?
How
high
do
we
go
and
probe
density?
If
you
want
to
say
it
that
way?
In
this
particular
case,
like.
A
Test
out
there
that
was
already
running
and
saying
you
can
inject.
You
know
we're
gonna,
we're
gonna
set
up
a
node
with
you
know,
maximum
pod
density,
whatever
that
is,
and
then
you
can
sort
of
inject
your
tests
into
it
or
we
have
to
set
it
up.
Maybe
that
that's
useful
I,
just
don't
it's.
F
A
F
I
mean,
as
that
particular
example,
I.
Don't
think
there
would
be
a
big
obstacle
today
to
saying
I'm
going
to
run
a
need
to
be
suite
and
as
part
of
the
ewe
Suite
I'm
gonna
generate
in
pods.
Like
the
framework
lets,
you
generate
template
pods
you're
gonna
generate
in
pods
until
it
hits
the
density
of
the
cluster
I
mean
as
a
reasonable
proxy.
F
Like
that's
actually
a
case
where,
like
you
I
mean
it
would
be
a
little
bit
and
I
think
the
most
Philly
part
would
be
deciding
exactly
how
you're
going
to
determine
what
Max
pod
density
is,
but
it
would
probably
be
pretty
reasonable
I'm
sure
we
could
dig
up
some
existing
functions
to
like
you
know,
list
the
number
of
nodes
and
then
that's
a
pretty
good
example
like
filter
out
control,
plane
nodes
and
multiply
by
Max,
pods.
Okay,.
A
F
D
Yeah
in
this
specific
example,
I
think
we
can
do
that,
it
will
be
I
mean
we
have
eviction
tests
already.
That
exercise
some
limits
on
the
machine,
and
this
one
will
also
be
trying
to
exercise
limits
on
a
machine
and
with
all
eviction
tests.
We
will
have
some
very
fragile,
like
whenever
we
have
machine
type
change
like
default
machine
type
change
like
everything
explodes,
so
we
still
have
some
issues
with
one
of
the
eviction
tests
that
we
cannot
understand
why.
D
Some
like
these
corporations
are
taken
slow
and
like
they
suddenly
started
taking
slow,
so
I
think
we
can
implement
this
particular
case.
I
was
wondering
how
we
can
catch
it
in
future.
Maybe
like
asking
for
tests
is
a
good
thing
and
I
really
like
this
first
question
about
what
limited
resources
are
not
it
will
utilize.
A
B
What
happens
if
it
gets
exhausted
down
the
note
and
have
you
tested
it,
but
I
mean
I,
don't
know
what
do
other
people
think
about
that.
F
Resource
exhaustion
seems
like
an
interesting
one
to
me,
just
because
I
feel,
like
kubernetes,
already
has
a
bunch
of
Dimensions,
where
you
can
do
this
to
a
cluster
that
aren't
well
defended,
so
I
feel
like
that
might
be.
The
actual
shift
here
is
towards
expecting
people
to
not
leave
these
trivial
resource
exhaustion.
F
Problems
in
future
features
like
that,
like
you,
I
think,
for
example,
it
wasn't
that
long
ago
that
you
could
still
do
just
like
a
fork
bomb
and
take
down
a
node
I
think
that
that's
generally
configured
to
not
be
possible
now,
but
there
are
like
a
bunch
of
other
fun
ones
that
I
notify
limits.
Inodes
I
think
we
don't
do
much
for
dealing
with
if
you
just
generate
a
whole
bunch
of
empty
files
and
leave
them.
F
It
doesn't
count
against
your
like
disk
limits,
but
you
can
still
trash
your
node
doing
that,
so
it
would
I
feel
like
it
would
certainly
be
raising
the
bar
to
expect
people
to
avoid
or
to
to
test
for
like
towards
resource
exhaustion.
E
But
having
the
question
I
really
like
the
the
question
that
you
do,
you
suggest
John
before,
like
about
the
resource,
exhaustion
and
I,
think
that
the
answer
to
that
question
may
trigger
some
some
comment
from
either
like
cap,
reviewers
or
us
to
add
some
graduation
criteria
to
to
to
have
some
tests
for
something
but
I
think
that
should
be
more
like
based
on
a
reflection
of
like
what
we
find
in
as
an
answer
to
this
question.
A
Okay,
well,
let's,
let's
add
that
maybe
Sergey
or
Vortec
or
somebody
or
I
mean
I
could
do
it.
But.
D
C
Yeah,
so
I
have
started
going
through
the
127
tracking
project
tracking
project
and
assigning
all
the
easy
ones.
So,
historically,
once
you
are
on
a
cap
that
one
is
yours
as
you
do
the
prr
for
every
transition
from
alpha
to
Beta
beta
to
GA.
That's
what
we've
done
in
the
past,
so
I
have
filled
in
those
numbers.
I've
done
the
same
thing
with
the
Shadows.
C
So
far
there
are
still
a
bunch
of
holes
and
I
guess
what
I
want
to
get
a
sense
of
is
what
we,
what
we
think
is
a
good
exercise
for
the
Shadows
to
do,
and
then
how
we're
going
to
try
to
get
good
balance
on
it.
So
I
have
a
pitch
for
the
first
one,
I
think
I.
Think
I
would
like
to
see
the
the
Shadows
take
the
primary
lead
this
time
and
do
the
primary
prr
review
for
as
many
as
they
think
they
can
fit
right.
C
I,
don't
want
to
overwhelm
someone
with
more
than
they
can
do,
but
trying
to
get
them
to
do
the
primary
and
then
do
the
second
sweep
after
as
opposed
to
before
I
think
we
were
trying
to
do
something
like
was
like
four
per
person
or
something
I
think
some
people
got
more,
but
you
know
we
were
bounded.
We
did
a
couple
together
and
then
we
reviewed
as
a
group,
but
at
least
that's
what
we
did.
What
I
did
with
with
yeah
I
did
something.
C
Similarly,
this
time,
I'm
thinking,
independent
and
then
come
back
and
sweep
through
more
asynchronous
and
I
want
to
ask
I
want
to
ask
the
Shadows
whether
that
seems
useful
to
them
whether
they
feel
comfortable,
doing
it
and
I
guess,
there's
only
two
of
you
here.
B
C
G
C
There's
more
coming
in
there's
more
coming
in
all
the
way
this
week
and
that's
the
set
where
we
say
we
were
definitely
going
to
get
to
your
review
and
then
after
this
week
we're
still
gonna
try.
But
if
they
come
in
after
this
week,
we
don't
feel
bad.
So.
A
So
David,
how
would
this
work?
Okay,
so
typically
like
first
of
all,
I
first
cut.
That
sounds
awesome
to
me
right.
That
would
be
my
preference
too.
I
think
that's
the
way
people
will
learn
the
most,
but
then
I'm
wondering
how
it's
gonna
work.
So,
let's
say
typically
what
what
I
find
is.
There's
right!
There's
a
back
and
forth
I
mean
some
of
them
are
easy
and
some
of
you
just
do.
But,
but
sometimes
it's
you
ask
they
answer
a
question.
A
A
Do
we
step
in
and
review,
because
if
the
shadow
goes
through
this
iterative
process
over
several
days
with
the
person
and
then
we
come
in
and
look
at
it,
and
we
see
additional
questions
that
you
think
the
shadow
missed,
then
we're
going
to
start
the
iterative
process
over
again
and
it's
going
to
be
longer
so
I'm
trying
to
figure
out
what
point
we
step
in.
You
think
in
that.
B
C
I
had
not
thought
that
far
ahead.
That
is,
that
is
a
very
good
point.
Do
we
want
to
call
it
on
a
day
boundary?
Do
we
want.
G
To
say,
yeah
I
was
thinking;
we
we
need
a
deadline.
You
basically
need
the
Shadows
to
complete
the
reviews,
like
almost
immediately
like
literally
almost
immediately,
because
we
don't
have
a
lot
of
time
left,
that's
kind
of
why
I
signed
myself
10
of
them,
because
I
was
like.
We
kind
of
need
to
do
this
now.
E
So
so
I
I
have
I
have
a
suggestion
that
we
actually,
as
the
the
like
PR
approvers,
we
actually
take
a
a
Passover
over
the
the
ones
over
ones
that
were
reviewed
about
by
like
shadowverse
like
immediately
after
the
first
pass,
just
to
take
the
just
to
just
to
take
a
look.
If
there
isn't
anything
big
that
we
would
also
ask
about,
so
that
it
won't
be
missed
later.
That's.
A
C
That
would
that
would
work
for
me,
and
so
we
would
just
be
looking
for
some
slack
message.
Saying
I've
done
this
one
and
I
prioritize
messages
from
from
Han
Jeremy
Joe,
all
those
people
that
would
work.
A
Is
asking
is,
should
we
meet
more
frequently
I,
don't
know
if
we
need
to
meet
as
a
group,
we
need
to
keep
in
constant
contact
on
slack,
like
I'm,
open
to
Media
as
a
group,
not
a
problem,
but
my
point
is
like
a
lot
of
times
these
meetings
as
a
group
are
more
just
Logistics
they're,
not
execution
of
the
the
process,
so
I.
G
Was
I
mean
both
I
actually
I?
Think
we
need
both
like
right
one.
We
need
to
do
the
shadowing
stuff,
and
probably
we
can
do
a
lot
of
stuff
async,
but
syncing
up
will
probably
help
with
communication.
First,
some
of
the
more
tricky
things
that
we
run
into
or
whatever,
but
people
with
caps
who
have
like
they
basically
need
office
hours
and
if
prr
meeting
is
bi-weekly
and
PR
freeze
is.
G
I
mean
it
might
turn
out
that
no
one
shows
up
like
oh
yeah,
Google.
A
B
C
C
G
G
A
C
Swear
moved,
it's
not
worth
me.
Looking
it's
kind
of
worth
me.
Looking,
okay,
I
didn't
realize
we
had
that
much
time.
The
more
you
know.
A
A
Come
in
yeah,
okay,
so
so
next
week,
the
same
time
you're
thinking,
but
because
that's
what
that
would
be.
C
E
I
think
I
might
be
a
bit
late,
but
I
don't
want
to
block
this
so.
G
A
So
I'm
giving
it
to
your
suggestion.
You
want
to
send
out
the
email
I
can
book
the
assume,
wait.
We
have
to
make
sure
that
the
zoom.
A
So
if
you
want
to
send
out
a
note
for
that
use
this
same
Zoom,
link
and
I
can
add
it
to
the
cube
calendar.
G
G
F
Since
most
of
the
Shadows
aren't
here
and
I'm,
not
sure
where
exactly
we
wound
up,
can
we
have
a
follow-up,
reminding
everyone
like.
B
F
We're
expecting
over
the
next
like
week
or
two
before
the
freeze
hits
yes.
A
Hot
until
then,
as
I
just
said,
you
volunteered
yourself
to
send
out
a
note
to
the
other
Shadows
we've
got
them
listed
in
the.
A
The
logistics
are
the
the
Shadows
take
the
primary
lead
that
they
make
a
pass
first
pass
through
the
cap,
and
then
they
reach
out
to
the
approver
for
the
cap
on
slack
and
say,
I've
made
my
first
pass.
That
approver
should
make
their
pass
in
the
next.
You
know
day
or
so
from
that
as
quickly
as
possible,
and
just
make
sure
that
all
the
big
issues
have
been
raised
to
the
author
of
the
cap
and
then
from
there.
A
The
the
shadow
will
manage
that
conversation
with
the
author
and
can
obviously
reach
out
to
the
approver
if
there's
something
they
think
needs
they're,
not
sure
about,
but
in
general
it's
in
the
responsibility
of
the
Shadow
to
manage
that
through
and
in
the
end
you
know,
we
still
should
probably
give
people
a
little
extra
time.
We
should
have
to
probably
have
the
approvers
come
in
one
more
time
with
enough
time,
for
you.
F
C
So
I
think
we
will
continue
to
get
things
arriving
all
the
way
up.
Until
then,
yeah
I
would
ask
that
people
get
on
the
ones
they
can
to
have
a
total
of
10,
maybe
Target,
something
like
three
per
day.
C
There
you
go
and,
and
that
way
we
can
be
sort
of
right
behind
with
the
Nexus
so
that
it
is
not
serial.
That
was
a
good
thought.
John.
G
C
G
G
C
C
Can
continue
to
have
a
back
and
forth
until
okay,
they
can't
freeze
okay,
what
it
is
we
we
experience
this
with
Alana
well,
actually
even
before
that,
but
she
suggested
the
solution
where
people
were
opening
caps
up
like
the
day
before,
like
can
you
give
us
a
production
rate
in
this
review
and
the
answer
was
I
can,
but
you
didn't
pass
and
it
became
really
awkward
where,
like
at
certain
point,
I
gotta
say
no,
and
this
gave
us
a
you-
have
to
have
it
written
by
this
date.
A
F
That
makes
sense,
yeah
I
mean
I,
can't
for
all
the
other
Shadows,
but
I
always
have
like
at
least
a
dozen
things
going
on.
So
having
some
kind
of
idea
like
okay
I
want
to
help
everyone
get
their
kits
through,
and
it
needs
to
happen
by
like
this
date,
helps
make
sure
that
I'll
like
prioritize,
get
getting
to
it
before
then.
A
Okay
so
we're
going
to
see
emails
from
an
email
from
Han
to
kdev
we're
going
to
see
email
from
Ben
to
all
the
Shadows
on
us
and
we're
gonna
see
a
PR
from
playtech.
A
B
F
I
feel
like
for
me,
I
want
to
leave
a
comment
like
in
like
early
in
my
comment
that,
like
okay,
I
I'm
shadowing
this
and
this,
but
also
like
you
know
this
person
is
your
yes
approver,
so
they
understand
like
what's
happening
like
we
can
point
them
at
the
tracking
board.
But
people
don't
click
links
no.
G
B
A
B
Cycle
period,
you
know
first,
we're
gonna,
have
these
shadows,
and
here
who's
here
they
are.
If
that's
how
you
should
expect.
Second,
we're
adding
this
office
hours,
just
like
you
have,
but
just
one
little
one
more
sentence
in
the
beginning
as
an
intro
would
be
helpful
just
to
set
context.
B
A
I
just
said
just
add
one
one,
paragraph
one
sentence
in
the
beginning
to
give
the
context
of
not
just
a
couple
of
things
to
announce,
because
they
don't
know
that
you're
a
PR
person
when
you're
sending
this
you
just
have
to
say
the
pro
group
has
decided
to
make
a
few
small
tweaks
to
process
this
cycle.
Here's
what
they
are
just
give
them
the
context.
Instead
of
announcing.
A
B
A
Okay,
then,
thank
you,
everybody
and
have
a
great
week,
we'll
see
you
Tuesday
and
on
slack
before
that,
I'm
sure
is.
F
F
F
Okay,
thanks
I'll
track
down
emails
and.
C
F
A
Everyone,
thank
you
all
good.
This
is
great
I.
Think
I'm
excited
to
get
this
at
this
process
expanded
to
more
people,
so
yep
thanks,
Mom,
okay,
bye.