►
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).
A
This,
I
think,
is
going
to
be
a
pretty
quick
meeting.
We
have
made
some
awesome
progress
thanks
everyone.
I
just
have
to
call
this
out.
This
is
going
to
go
nowhere,
but
we
have
no
blockers
left
on
our
v1
alpha
1
milestone.
We
have
got
everything
in.
I
think
it
was
harry's
pr
yesterday
that
merged-
or
maybe
it
was-
I
don't
know
whenever
it
merged
that
got
us
past
our
last
blocker.
So
thank
you
to
everyone
who
contributed
there.
A
I
I
think
we
are
good
to
go
for
v1
alpha
1
launch,
but
I
but
there's
also
some
great
pr's
in
progress
to
get
some
of
our
nice
to
haves
and
as
well
so
spend
a
little
bit
of
time
going
through
those-
and
one
thing
I
wanted
to
mention.
I
know
well
we'll
look
at
the
milestone.
There
have
been
some
like.
We
have
three
prs
right
now
that
are
up
against
v1
alpha
one
nice
to
haves
and
that's
awesome.
A
It
would
be
great
if,
in
addition
to
that,
if
you
know,
I
think,
let's
see,
I
think
one
of
these.
Oh,
I
should
close
this
myself.
I
fixed
sorry,
I
I
did
not
solve
it
well,
I
my
pr
this
morning
fixed
this
and
I
didn't
appropriately
close
it
so
I'll
deal
with
that,
but
danny,
and
I
think
you
had
volunteered
for
one
of
these
as
well.
A
So
yeah
that's
great.
A
But
I
think
I
think
we
are
getting
awfully
close
here.
We
have
conformance
test
framework
this
one.
I
think
we
might
be
able
to
close
yeah.
Okay,
we're
actually
in
a
good
place
on
all
our
nice
to
haves
as
well.
B
A
B
It
really
it
borrows
a
lot
from
the
http
route,
api
docs,
but
kind
of
puts
everything
on
a
single
page,
that
you
know
a
user
that
is
interested
in
understanding
and
experimenting
with
service
apis.
I
feel
like
one
of
the
first
things
that
they're
going
to
do
is
mess
around
with
an
http
route
and
so
having
you
know,
a
simple
guide
top
to
bottom.
That
gives
some
background
walks
through.
So
you
know
what
a
route
can
http
route
consists
of
specifically
around.
You
know
the
matching
rules
and
so
forth.
A
B
C
I
cancelled
it
because
I
have
to
break
it
up,
but
I
was
planning
on
doing
that
later
today.
Okay,
I
could
share
for
a
second
what
it
looks
like
and
we
can
talk
about
the
structure
because
I
think
sure
damn
example
would
help
a
lot.
In
addition,
sure.
C
C
I
am
sharing
my
screen.
Okay,
so,
first
of
all
I
felt
like
we
really
need
a
much
better
introduction
page.
That
kind
of
for
someone
doesn't
know
what
it
is
that
very
quickly.
Like.
Oh,
okay,
I
get
it,
you
know
what
is
it?
How
is
it
different
from
ingress?
C
What
does
it
do
where
to
get
started,
api
reference
and
guides
and
then
how
to
get
involved,
which
is
kind
of
links
to
so
it's
just
kind
of
like
an
expansion
of
the
existing
intro,
and
then
we
have
the
the
concepts
I
I
did
think
that
there
is
the
api
concepts
right
now
is
kind
of
a
combination
of
design
topics
that
were
like
more
for
like
hey
here's,
our
thoughts
behind
the
design
and
api
concepts
were
like
here's,
how
it
actually
works,
and
so
I
did
separate,
I
didn't
think
it
made
sense
to
separate
those
out
into
api
concepts
and
design
concepts.
C
Like
some
of
the
things,
I
think
that
harry
wrote
around
conflicts
and
performance.
I
I'm
not
sure
where
this
originally
came
from,
but
I
thought
these
were
kind
of
separate
from
like
how
the
api
actually
works,
they're
kind
of
like
the
theory
behind
the
api.
D
So
I
think
that
makes
sense
to
split
it
out.
There
is
already
a
couple
of
pr's
that
have
been
merged
in
which
does
a
little
bit
of
exactly
this,
but
a
little
differently.
So
there
will
be
some
conflicts
for
sure
mark.
A
C
D
I
love
it
it's
merged
when
it
is
in
progress,
but
whatever
you
have
inside
the
api
concepts
page
mark,
I
think
we
should
definitely
move
like
you
should
be
at
it
and
like
we
should
get
that
in.
Like
there's
a
lot
of
valuable
updates
here,.
C
Yeah,
okay,
I'll
just
do
small
updates,
so
it's
easier
to
merge
it
and
then
for
the
the
gateway.
I
think
we,
I
think
couple
of
us
had
us.
You
know
each
of
us
had
a
simple
gateway.
One
probably
the
same
kind
of
idea
is
just
like
what
is
the
absolute
bare
minimum
simplest
route.
You
can
do
essentially
no
matching
at
all,
just
send
it
directly
to
one
service:
they
match
all
traffic
and-
and
so
that's
what
this
was.
C
Okay
and
then
daniel,
your
your
updates
might
be
helpful
here.
I
don't
have
a
whole
lot
of
text.
I
just
have
kind
of
an
image
and
then
kind
of
an
example
of
kind
of
what
just
showing
the
different
varieties
of
matching
that
are
possible
and
showing.
E
A
I'm
just
thrilled
to
see
graphics
in
here.
That's
next
level
here.
C
F
C
I'm
big
on
the
images,
but
I
I
also
shared
this
in
the
deck
of
these
images,
so
we
can
start
using
them
in
a
consistent
way.
So
a
few
examples,
I'll
ping,
the
the
link
in
the
chat,
and
so
if
you
want
to
just
add
to
the
same
deck
and
we
can
keep
all
the
images
in
the
same
deck
and
we'll
have
consistent
imagery
throughout
all
the
docs
awesome.
I
used
these
cisco
icons
just
because
they're,
like
the
most
standard
thing
out
there,
cool.
B
C
I
guess
I
didn't
contribute
the
multi-tenant
gateway
one
wee
yet,
but
that
is
basically,
you
know,
get
cross
namespace
gateways
and
routes
and
showing
just
how
that
works
with
different
teams.
A
I
think
it
would
be
really
valuable
if
you
made
a
pr
to
add
the
two
guides
that
you
do
have
the
simple
gateway
and
complex
routing.
I
think
those
are
awesome.
I
I
you
know,
having
looked
at
them
just
now
and
then
maybe
a
separate
pr
for
the
rework
of
the
intro
page,
because
I
think
that's
also
well,
let
me
whatever
our
main
page
is,
I
think,
that's
yeah.
D
C
A
B
Everyone
see
my
screen:
okay,
yep
right,
so
we
basically
just
dropped
a
new
guide
in
here
for
http
route.
I
used
harry's
tls
guide
along
with
the
api
docs
as
kind
of
the
guardrails
for
this,
but
as
I
mentioned,
I
thought
okay.
B
Well,
this
you
know,
http
route
will
be
another
one
of
the
first
routes
that
users
want
to
play
around
with
give
them
a
quick
introduction
of
what
http
route
is
and
the
rules
right,
quick
illustration
and
different
a
little
different
than
what
you
did
mark
with
using
kind
of
the
cisco
icons.
You
know
I,
as
I
mentioned
before,
kind
of
look
at
our
the
our
ingress
documentation,
and
I
kind
of
use
that
for
guidance
here,
and
so
that's
why
this
looks
and
feels
very
similar.
B
But
you
know,
I
think,
the
keys
to
the
http
route
is,
you
know,
matches
with
the
filters
and
the
forward
too
so
spend
some
time
putting
it
together.
The
diagram.
B
Need
to
add
the
forward
to
and
then
an
http
route
example,
and
it
seems
like
maybe
with
your
guy
burr,
maybe
instead
of
this
being
a
kind
of
a
simple
example,
maybe
I
make
it
a
little
more
complex
or
you
know
I
just
keep
this
as
whip
and
then,
when
you
merge
your
stuff
in,
maybe
I
rework
it
into
your
stuff
or
I
don't
know,
I
don't
know
what.
C
Yeah,
I
was
gonna
say
this
looks
really
awesome,
and
but
it
does
feel
a
little
more
conceptual
rather
than
a
guide.
I
wonder:
if
does
this
belong
better
in
the
api
concepts
guide
or
the
api
concept
page.
A
B
And
rob
I
agree
with
you
for
every
api
type.
I
think
having
something
like
this
would
be
helpful.
So
maybe
this
is
kind
of
the
first
step
towards
that
cool.
A
Yeah
I
mean
this
is
this
is
a
great
pattern
to
follow
and
copy
for
other
route
types,
and
you
know
I
think,
especially
if
we
had
something
comparable
to
this
for
a
gateway
that
would
be
really
helpful.
C
Yeah
so
there
will
be
like
so
there's
like
the
api,
like
general
api
concepts,
page,
which
kind
of
is
a
high
level
concepts
for
everything
and
then
there'll
be
a
breakout
page
for
each
like
gateway
concepts,
hp
route
concepts.
Is
that
what
you're
thinking.
A
Yeah
it
could,
it
could
be
inside
concepts,
it
could
also
be
inside.
I'm
not
sure
how
it's
almost
like.
We
need
a
new
section,
almost
a
new
resources
section
or
or
something
like
that
and
then
have,
and
then
we
can
maybe
split
out
okay,
so
whoever's
screen
sharing
right.
Now
we
have
the
api
resources
page,
which
is
kind
of
a
start
for
each
one,
so
we
have
so
maybe
gateway,
class
gateway,
etc.
A
A
Then
we
have
pages
for
each
resource
inside
that
I
don't
know.
B
Yeah,
well
let
me
let's
let
me
play
around
with
this.
Let
me
spend
some
more
time
looking
through
just
how
the
concepts
are,
are
organized
yeah
and
then
I'll
move
this
from
a
guide
into
the
concepts
as
part
of
kind
of
a.
B
A
You
mind:
do
you
mind
taking
a
look
at
the
resources
page,
one
more
time
it
seems
like
we
have
a
significant
amount
of
content
around
gateway
class
and
then
another
significant
amount
for
gateway.
C
A
C
I
mean
I
think
these
could
just
be
all
under
concepts
really
where
it's
just
like
one
is.
The
api
concepts
page
becomes
a
page
called
like
overview
and
then
there's
a
gateway,
one
gateway
class,
hp
route
and
they're
all
conceptual
on
nature.
A
A
B
Yeah
I
like
this,
so
api
concepts
becomes
like
api
introduction
api
overview,
something
like
that.
C
B
A
B
A
B
On
that,
as
part
of
this
part
of
this
prl
push.
D
One
general
note:
I
think
this
was
robert
brought
up
this
previously
so
right
now,
whenever
we
have
any
ammo
or
manifest
snippets
in
in
documentation,
we
make
sure
to
add
it
into
the
examples
directory
in
the
repository.
So
that
takes
care.
You
know,
if
you
have
any
breaking
points,
I
don't
know
our
examples
are
up
to
date
and
manifesting
documentation.
C
B
D
We
have
yaml
manifests
that
are
being
displayed
inside
our
guides.
Currently,
those
are
all
references
to
yaml
files
inside
the
examples
directory
right.
So
what
that
gives
us
is
that
if,
in
our
ci
run,
we
make
sure
that
those
yamls
are
valid
at
least
syntactically
valid,
and
you
know
they
apply
to
a
cube
cluster.
D
So
that's
how
we
have
organized
it
right.
We
have
not
put
in
any
yaml
directly
inside
inside
the
guide
itself
right
like
like,
if
you
see
here
you
have
that
include
directive,
so
that
takes
care
that
you
know
our
documentation.
Don't
get
out
of
sync
with
our
with
our
types
and
crds.
B
Yeah,
I
know
absolutely
let
me
let
me
just
share
my
screen
again.
I
don't
mean
to
just
snatch
that
away
from
me,
but,
for
example
like
in
my
http
route
work
here
now
this,
because
it's
just
kind
of
like
a
snippet
of
an
example
resource
this
doesn't
call.
B
B
So
again,
I
followed
kind
of
what
you
did
with
the
tls
guide,
where
the
full
example
which
is
this
down
here,
comes
from
the
examples
directory
so
that
whenever
this
example
gets
updated,
this
will
be
updated
as
well.
But
when
it's
just
kind
of
like
a
snippet
here,
I'm
not
sure
if
there's
like,
should
we
well.
C
I
think
that's
okay
in
the
conceptual
section,
basically
the
point
of
the
the
guides-
and
I
like
I
like
it
when
guides-
are
totally
atomic
and
self-encompassing
and
that
like
they
can
be
executed
on
their
own.
So
generally
they
should
be
relatively
small
and
each
guide
should
have
the
email,
but
for
the
conceptual
pages
where
we
have
snippets,
we
don't
have
to
save
that
because
that's
not
like
actual
anything.
You
can
run
because
it's
just
show
it's
just
conceptual,
but
each
guide
should
be.
C
If
you
had
a
gateway
controller
available
to
you,
there's
something
you
could
take
it
and
you
could
deploy
the
whole
thing,
and
so
each
of
those
should
definitely
have
each
of
the
each
of
the
guides
should
represent
exactly
one
deployment
like
some
one
thing
that
one
use
case
and
each
of
those
should
have
the
full
example
in
the
ammo.
In
that
examples,
folder.
B
Yeah,
and
so
whenever
I
kind
of
call
out
like
with
this
example,
it
does
come
from
our
examples
directory,
but
I
you
know,
I
think,
where
I've
seen
in
other
places
in
our
docs,
when
it's
just
kind
of
like
a
a
portion
of
a
resource
or
something
like
that
that
that's
actually
embedded
and
again,
I
I
try
to
kind
of
use
harry
your
tls
guide,
as
as
a
reference
does
that
make
sense
to
you
I
mean
I.
A
So,
just
as
well
actually
well,
you
still
have
that
up
or
if
you
don't
mind,
pulling
that
back
up.
Sorry,
one
one
thing
I'm
wondering
here
is:
if
we're
going
to
have,
if
we're
pulling
this
out
of
guides
and
into
concepts,
maybe
that
last
section
shouldn't
actually
include
that
full
example
and
it
should
instead
just
reference
guides
that
use
this
resource.
So
as
an
example,
this
is
http
route
and
you
know
for
further
reading.
Try
these
guides
out.
Try
these
specific
examples.
A
B
B
Okay,
cool,
you
know
and
I
could
stop
sharing,
but
I
think
bowie
brings
up
a
good
point
on
chat
may
seem
insignificant,
but
it
would
be,
I
think,
cool
to
have
a
logo
associated
with
the
project.
C
A
A
Yeah,
I
don't
know,
I
don't
know
how
to
how
to
arrange
for
that,
but
I
I
feel
like
it's
possible,
maybe
maybe
mark
you-
seem
to
have
some
level
of
graphical
knowledge
or
connections.
Maybe
you
can.
C
C
Let
me
let
me
see
if
I
can
cut
with
something
or
you
know
what
I'll
just
go
and
pull
some
people
that
know
things
about
ux
and
ui,
and
we
can
see
if
we
can
get
a
cool
logo.
C
A
A
Me
pull
this
back
up
all
right,
so
yeah,
that's
exciting!
It's
really
awesome
to
see
the
the
product
rest
on
docs
come
together.
I
think
we're
on
pace
a
lot
to
have
a
really
compelling
v1
alpha
one
launch.
So
thanks
to
everyone
for
getting
that
together,
pull
back
up
the
v1
alpha
one
milestone
and
I'll
look
at
the
ones
that
are
important
soon.
A
I
don't
see
rich
on
this
call,
but
I'll
follow
up
with
him
after
I
think
he
knows.
The
little
bits
left
to
do
on
this.
One
harry
has
a
pr
which
we'll
cover
today
on
case
sensitivity
for
a
header
matching
same
for
listener
status.
A
We
have
lots
of
work
going
on
for
documentation
and
user
guide
and
conformance
test
framework
is
something
like
that
we've
talked
about,
but
yes,
it's
certainly
not
anything.
We
need
to
solve
between
now
and
wednesday,
so
yeah,
okay,
great,
I
think
harry-
has
mentioned
here
that
maybe
we
don't
need
a
user
guide
specific
issue
anymore,
because
we
have,
I
created
another
issue,
that's
awfully
similar,
which
is
adding
examples
to
documentation.
A
A
Cool
all
right,
I
will
keep
on
running
then
there's
a
couple
pr's
from
harry.
That
would
be
great
to
get
through
I've
added
some
initial
feedback
here,
but
there
there
was
some
ambiguity
around
header
matching
and
specifically
case
sensitivity
and
harry
you've
updated
some
bits
here.
I
I
had
a
couple
additional
suggestions,
but
the
the
key
is
that
obviously
header
field
names
have
to
be
matched
case.
A
Insensitively
to
you
know,
go
along
with
the
rfc
rfc,
but
the
rfc
does
not
say
anything
about
case
sensitivity
inside
the
header
field
value.
So
I
that's
a
little
bit
more
and
better.
A
C
A
Value
is
case,
sensitive,
sure
sure,
but
where
I'm
going
with
this
is
we
have
a
regular
expression
type
that
it
is.
It
is
certainly
conceivable
that
you
could
put
a
you
know,
slash
eye
in
your
regex
and
then
it
would
be
case,
insensitive
matching,
and
so
we
don't
want
whatever
we
put
in
our
spec,
we
don't
want
to
prohibit
case
insensitive
regex
matching,
so
we
don't
want
to
be
like
so
you
know
so
sold
on
case
sensitive
matching
that
we
exclude
this
potential
use
case.
G
E
G
D
G
E
D
So
I
think
we'd
know
that
you
know
header
names
are
not
case.
Sensitive
and
header
values
are
case
sensitive,
but,
and
we
do
not
want
to
be
prescriptive
of
how
regular
expression,
the
header
match.
Type
of
regular
expression
translates
into
like
case
sensitivity.
Is
that
right.
A
That
that's
where
I
was
going
with
that,
but
if,
if
there
really
is
universal
support
like
if
it
is
universally
used
as
case
sensitive,
which
seems
likely,
then
then
maybe
it
is
fine
to
say
every
header
match
value
needs
to
be
case,
sensitively,
matched
just
trying
to
think
of
any
potential
exceptions.
To
that
rule.
G
I
mean,
if
you're
doing
like
perl
compatible,
then
you
have
all
these
options.
Like
parentheses
question
mark,
I
parentheses,
but
it
just
seems
like
we
can't
really
say
anything
about
like
we
haven't
specified
what
syntax,
whether
it's
pcre
or
basic
or
extended
posix
or
what
so
it
seems
like.
There's
no
reason
we
should
be
prescriptive
about
case
sensitivity
within
regular
expression
matching
if
we're
not
prescriptive
about
the
rest.
A
A
So
I
guess
that
that
comes
to.
Where
do
we
draw
the
line
on
implementation?
Specific,
because
even
implementation,
specific
things
we
do
provide
some
basic
set
of
guidance,
maybe
obviously
exact
does
need
to
be
a
case,
sensitive
matching,
but
maybe
for
both
regular
expression
and
implementation,
specific
matching.
We
say
it
is
up
to
the
implementation
or,
as
far
as
case
sensitivity,
regular.
E
G
E
E
A
Right,
so
so
what
okay?
So
let's,
let's
back
up
a
second,
we
do
need
to
say
that
field
names
must
always
be
matched
case
insensitively,
and
that's
that's
solved
by
this
bit
here.
A
What
the
the
majority
of
this
discussion,
I
think
is
about
is
how
we,
how
we
specify
how
head
or
match
type
should
be
used
as
far
as
case
sensitivity
right
here,
we've
said,
field
value
matches
are
case
sensitive.
Is
that
appropriately
descriptive?
We
should
just
delete
that
statement.
A
A
Should
we
it
feels
it
feels
like
there
is
value
in
in
saying
that
for
at
least
exact
match
that,
because
this
is
something
that
is,
is
reasonably
well
specced
and
so,
in
that
case
to
say,
okay,
this
is
also
case
sensitive
and
then
to
leave
regex
and
implementations.
Don't
you
have
to
put
that
statement
everywhere?
You
match
a
string.
B
A
I
I
think
I
think
there
could
be
some
confusion,
because
we're
saying,
because
we've
gone
out
of
our
way
to
say
that
this
adjacent
value-
this
you
know
the
field
name-
is
case
insensitive,
so
it
could
help
to
say,
but
the
value
is
not.
A
E
A
Yeah
it's,
this
is
a
little
can.
I
think
I
think
we
need
to
clean
this
up
a
little
bit
because
there's
some
documentation
here
for
header
matching
and
some
up
here.
E
A
A
Yeah,
okay,
so
it
seems
like
there
is
at
least
some
value
in
clarifying
that,
at
least
for
header
match
type
exact
field
value
matches
are
case,
sensitive
and
then
not,
and
then
this
statement
here,
the
regular
expression-
and
I
think
this
will
also
generally
applies
to
implementation.
A
Specific
just
read,
the
implementations.
Documentation
seems
appropriate
here.
F
A
A
I
don't,
I
think
I
think
it's,
I
think,
just
a
little
bit
better
documentation
go
doc
around.
It
is
fine.
Okay,.
A
A
C
A
The
okay
sure
value
match
type
sure
the
next
one
is,
I
think,
pretty
straightforward.
A
We
came
into.
I
think
this
was
from
pre-alpha
api
review
feedback.
We
we
got
some
feedback
that,
with
our
updates
to
listener
port
may
not
be
sufficient
to
uniquely
identify
a
a
listener
eric
you
can
actually
provide
context
here.
D
D
D
I
opted
for
this
instead
of
adding
a
name
of
the
on
the
listener,
because
that
felt,
like
you
know
like
like
another
field,
that
the
user
is
another
name,
that
a
user
has
to
think
about,
and
it's
not
really
necessary.
So
yeah,
that's
what
it
does
like
just.
I
tie
the
status
to
the
correct
listener.
That's
some
metadata!
We
are
adding
here.
A
Yeah
thanks
thanks
for
doing
this.
This
is
this
is
my
preferred
approach
as
well
to
solve
this.
I
I
already
approved
this
pr,
but
I
wanted
somebody
else
to
sanity,
check
it
and
add
an
lgtm,
but
I
I
think
this
is
remarkably
straightforward
and
a
good
improvement.
A
I
think
that's
fair
yeah,
that's
fair!
I
I
think
the
issue
with
adding
a
name
to
listener.
Is
it
just
adds
that
kind
of
overhead
for
users,
like
I
imagine,
this
being
a
relatively
the
the
host
name
being
required
being
a
relatively
rare
thing?
Maybe
it's
not,
but
the
idea
that
even
for
the
simple
use
cases
you
have
to
add
that
additional
field
that
listener
name
feels
unfortunate,
and
you
know
as
much
as
we're
trying
to
build
an
advanced
api
that
solves
you
know
as
many
use
cases
as
possible.
A
That's
my
bias.
I
don't
know
if
that's
the
correct
approach,
but
that's
where
I
tend
to
lean
towards
very
harry.
I
don't
know
what
were
you
thinking.
D
D
Like
that,
in
most
cases
you
know,
I
think
this
would
be
enough
like
just
adding
a
protocol
to
a
listener
would
be
enough.
If
somebody's
configuring
a
lot
of
host
names.
Like
then
yeah
this
becomes
a
little
complicated,
but
I
think
that
would
be
a
smaller.
D
It
would
be
a
smaller
fraction
of
our
users.
Who
would
do
that?
So
it's
still,
you
know
adding
enough
metadata,
but
not
you
know,
sort
of
overwhelming
the
user
or
the
implementer.
A
Is
there
is
there
room
for
middle
ground
here?
I
don't
even
know
that
I'm
actually
suggesting
this,
but
just
throwing
it
out
there
of
removing
hostname
and
kind
of
falling
back
to
this
weird
thing
of
if
port
and
protocol
overlap
like
if
they're
reused,
multiple
times
they
are
collapsed
into
this
one
status.
D
Yeah,
I
think
so
we
could
do
that.
The
only
reason
is
then,
I
would
expect
you
know
like
host
name
being
same
right
like
like,
like
what
kind
of
statuses
would
be
reported
in
that
case
right,
like
one
listener,
you
know
like
there
are
multiple
any
like
you
know,
hit
a
hostname
match
type
of
any
listeners
and
things
like
that
right
and
there
the
hostname
actually
does
carry
some
value
there.
So
yeah,
that's
it.
You
mean
it.
D
That's
why
I
thought,
like
you
know,
let's
keep
it
optional
and
the
implementer
can
decide
to
skip
host
name
all
together,
right,
which
probably
you
know,
does
not
complicate
things
a
bit
too
much.
A
A
A
A
Great
okay!
Well,
I
know
we're
past
time
here,
but
yeah.
Thank
you
for
the
the
work
on
these
pr's.
Just
let
us
know
whenever
you
update
these
and
I'll.
Take
another
look
yeah
great,
we'll
talk
to
everyone
next
when
well,
this
coming
wednesday
for
a
live
v1
alpha
1
release
that
should
be
fun
have
a
great
rest
of
your
week.